One Article Review
| Source |  Veracode |
|---|---|
| Identifiant | 2496162 |
| Date de publication | 2021-03-16 10:45:23 (vue: 2021-03-17 16:05:27) |
| Titre | Automated Security Testing for Developers |
| Texte |  Today, more than ever before, development organizations are focusing their efforts on reducing the amount of time it takes to develop and deliver software applications. While this increase in velocity provides significant benefits for the end users and the business, it does complicate the process for testing and verifying the function and security of a release.
The days of long-running, waterfall-style development cycles, wherein security was manually evaluated and bolted on at the end, are gone for good. With the move towards an agile development methodology, security testing and remediation is inherently shifting to the left. And to support this, developers must adopt tools to automate security testing for easy vulnerability identification at the earliest point possible in the development lifecycle.
Below, we discuss the why and how of implementing an effective strategy for automated security testing within the development lifecycle.
Shifting security testing to the left
Through the use of automation, security testing can be executed earlier (or left) in the development pipeline. This is advantageous for a variety of reasons. For one, the earlier vulnerabilities are discovered, the less expensive they are to fix. If a security issue was introduced into the code early in the release cycle, it???s more likely that it???ll be resolved in minutes or hours. Whereas, a vulnerability discovered at the end of the release cycle could face complexity that increases the time required to remediate.
Moreover, earlier execution of security tests ensures that vulnerabilities pose less of a threat to the delivery schedule. When security tests are automated as part of the build and integration processes, there is less uncertainty as the release approaches the later stages of the development lifecycle. This reflects well on both development personnel and the organization as a whole.
Shifting security left can also help reduce security debt, which piles up over time and can only add to serious risk if left unchecked. Instead of leaving the prioritization and remediation of bugs and vulnerabilities until the very end, shifting security left encourages collaboration between security and development to tackle this issue and determine which security debt is acceptable, and which should be remediated ASAP, reducing lingering risk.
Automated security testing for developers
So with the intent being to automate and shift security testing to the earliest possible point in the development lifecycle, let???s analyze how this is done in practice.
What are we looking for when we test? What does automated security testing involve?
Automated security testing for applications is accomplished by scanning code for vulnerabilities. Static code analysis, for instance, scans a codebase while the application is not running. The code is evaluated against a set of policies to ensure that developer implementation is in compliance with the security standards set forth by the organization. Non-compliance with any standard would indicate a vulnerability. These vulnerabilities can include anything from failure to properly protect database calls from SQL injection, to non-compliance with PCI standards for processing, storing, and transmitting credit card information. Furthermore, automated security testing can be leveraged to validate the security of third-party libraries being used by the system.
Organizations that wish to shorten their development cycles and enable continuous delivery should uti |
| Envoyé | Oui |
| Condensat | 000 130 ability able about acceptable access accomplished according accuracy actionable add addressing adopt advantageous advantages against agile allow allowing also amount analysis analyze any anything api apis application applications approaches appsec are aren asap aspects associated assume automate automated automation availability based before being below benefits between bolted both bugs build business but calls can card choice ci/cd close cloud code codebase coding collaboration come comes committed committing complexity compliance complicate composition configuration configured consider considerations considering consistently construct continuous continuously contrast convenience cost could credit critical culture cycle cycles dast data database day days debt deemed defects deliver delivery deployment detection determine develop developer developers developing development devops discovered discuss does done dynamic earlier earliest early easily easy eclipse effective efficient efforts enable enables enabling encourages end engagement ensure ensures ensuring entire equip equips evaluate evaluated evaluating ever executed executing execution exist expensive face facilitates fail failure fast features feedback first fiveﾂ fix flaw flaws focusing forces forms forth from function functionality furthermore gain game get gitlab gone good guide: hardware have help helping helps higher highest highly hours how ide identification identified identify ides immediate immediately immensely impact impactful impacting implementation implementing importance important improve include including increase increases indicate information infrastructure inherently injection innovation insights installation instance instead instill integrate integrated integrating integration integrations intellij intent introduced involve issue jenkins just kicked later latest learn leaving left less let level leverage leveraged leveraging libraries lifecycle like likely lingering long looking low lower major making managing manner manually many means methodology mind minutes modern more moreover move must name non not off often one only options organization organizational organizations other outset over overhead part party pci percent personnel perspective piles pipeline pipelines place platform platforms point points policies pose possible practice practices premises present prevent principles prior prioritization problems process processes processing progression properly protect provide provides providing question read real reasons reduce reduces reducing reflects release released releases remediate remediated remediation report reported repository require required resolved resources result risk running sacrificing said sca scalable scan scanning scans schedule sdlc secure securing security sense serious service set several severity shared shift shifting shorten shortfalls should significant simplified software solutions some specific sql stages standard standards state static stifling storing strategy streamline style such support surefire system systems tackle takes talking tasked team teams terms test testing tests than thereby therefore these third those threat through throughout time today tool tooling tools toolset towards transmitting unacceptable uncertainty unchecked undoubtedly until updated upgrading upon use used users utilize v11 validate valuable variety velocity veracode verifying very vscode vulnerabilities vulnerability waterfall way well what when whereas wherein which whole why will wish within without would wrapping your |
| Tags | Tool Vulnerability Threat |
| Stories | |
| Notes | ★★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.