This is the first in a series of blogs on how Veracode products fit into each stage of the software lifecycle – from development to production. We want to emphasize lifecycle here, because we continue to hear the misconception that application security falls squarely and solely into the testing stage. In our 10+ years helping organizations secure their applications, we’ve learned that effective application security secures software throughout its entire lifecycle – from inception to production or, put another way, from prevent to respond. Application security should be considered and conducted from the planning phase through to the development phase, on to the testing phase and right into production. In fact, rather than talking about securing the software development lifecycle, we should focus on securing the software lifecycle.
This blog series (and accompanying interactive infographic) will take that notion one step further and detail exactly how our products fit into each stage. We hope this series gives you a better sense of both the security requirements throughout the lifecycle and how Veracode can help at each step.
The Coding Stage
We always say to “shift security left as far as possible,” and we mean that literally. In fact, we think security testing should be involved from the very first line of code written. And with Veracode Static Analysis IDE Scan, that’s a reality – you get security feedback on your code in seconds, as you’re writing it. In this way, developers not only fix security issues when they are the easiest and less expensive to address, but they also learn from the feedback. With the real-time feedback, developers will learn to code more securely, and eventually will code without security-related defects the first time – which is truly creating secure code at DevOps speed. Our most recent State of Software Security (SoSS) report (based on our platform data) backs up this idea with some real numbers. This year, DevOps organizations that tested frequently with sandbox scanning (developer-initiated scans early in coding process) had a 48 percent better fix rate than those doing policy-only scanning (security team initiated scans before releasing to production).
What else improves security at the coding phase? Training developers to fix what they find, a skill set that is typically lacking. Our 2017 SoSS data shows that developer training leads to significant results. In fact, teams with developer eLearning in place improved developer fix rates by 19 percent. Even more impressive, remediation coaching (consulting services that offer analysis and advice to developers alongside the scan results) improved fix rates by 88 percent.
How Veracode Secures the Coding Stage
Veracode Static Analysis IDE Scan: Veracode Static Analysis IDE Scan finds security defects in your code and provides contextual remediation advice to help you fix issues in seconds, right in your IDE.
Veracode Developer Training: This training includes AppSec Tutorials for quick reference while coding, including subjects such as XSS, SQL injection and CRLF injection.
Veracode Developer Sandbox: With Developer Sandbox, individual developers or development teams assess new code against the required security policy — without affecting compliance reporting for the version of the application currently in production.
Veracode Security Program Management: Security program managers collaborate with their Veracode colleagues to coordinate on developer consultations, remediation advisory services and mitigation proposal reports.
The Build Stage
Veracode integrates with Jenkins, Visual Studio Team Services or Team Foundation Server build or release pipelines. With this integration, application security scanning is an automated step in the build or release process. Security testing simply becomes another automated test the build server performs, along with functionality and quality tests. In this way, developers can prevent an application from being released if it does not pass Veracode policy.
If a security-related defect with a certain severity rating or prohibited open source component is found in the build process, this integration also has the ability to “break the build” and stop it automatically before code is released with these security issues.
And thanks to Veracode’s low false-positive rate, you won’t break the build unnecessarily or frequently. Veracode’s build system integrations support integrating security testing both in stand-alone builds and as part of more complex pipelines. Depending on your team’s needs, you can configure security testing with each build, within a release pipeline, or as part of a special security pipeline.
How Veracode Secures The Build Stage
Veracode Developer Sandbox: Developers are able to measure the security posture of a new feature on a Developer Sandbox before committing code to the master branch.
Veracode Static Analysis: Upload a single packaged application to the Veracode Application Security Platform to kick off a scan and get a pass/fail result.
Get the Whole Picture
Check out our new interactive infographic, Securing Every Phase of the Software Lifecycle, to further explore security considerations during the SDLC, and how Veracode products fit into that picture.
And stay tuned for the next installment in this blog series, covering Veracode products in the testing stage.