For most developers, the words “Security Policy Review” can stir up images of long meetings late in a project, with corporate security officers pouring over their code with the scrutiny of a tax auditor. The meetings often end with a laundry list of dramatic changes to the code and architecture to meet the ever-present threats of the outside world.
In the best case, we go through this exercise and find that our code is in good shape, thanks to modern languages and platforms that are "secure by default.” In the worst case, we find that we have a lot of expensive mitigation late in the development cycle. Alas, the complexity and lack of time or expertise has an impact, making a rigorous approach to application security impractical. Enter DevSecOps, part of the ongoing shift left of groups outside of traditional development and operations, DevSecOps is now considered a best practice for any company that stores custom or client data.
Why DevSecOps is a Better Way Forward
The good news today is that modern deterministic languages, built on platforms designed to be "secure by default," give us an advantage. We can combine rich tooling automation with analysis based on the extensive historical data we've discovered during the Internet Age to catch software security issues and vulnerabilities before they start. The most prevalent practices for adding security into our development pipeline today include:
- Code Scanning - inspects code for known coding errors and security holes, including exposed connection strings, secret keys, buffer overruns, and more. These tools can be run to interactively command lines or IDEs, either during code commits or during automated builds in the staging pipeline.
- Dependency Scanning - checks a project's package dependencies for outdated versions or those with known compromises or vulnerabilities. Checks are done against an ever-growing database of third-party packages that have known documented issues.
- Vulnerability Management - offers tools that create a new branch, automatically apply best practice fixes, and submit as code commits for the team to approve.
The organizational benefits of shifting security left are well documented. According to the 2020 State of DevOps report, 45% of companies with security fully integrated into their delivery process are able to remediate critical vulnerabilities within a single day, compared to just 25% of less evolved DevSecOps organizations.
How to Get Started
Due to the costs of delaying a DevSecOps evolution, there's no time like the present to get started. Current tools are designed to be integrated directly into your build and deployment pipeline, so the barrier to entry is quite low. Here are some options for choosing an implementation policy – from good to better to best:
- Good: Run interactively as time allows during development – This approach is solid if you are starting out and/or have a legacy code base and anticipate a large number of issues to address. You can prioritize them and knock them down over time.
- Better: Scheduled sweeps of the code base – This option can be used in a governance capacity to get regular reports of exposure level and gauge risk to an organization. It’s a better choice for internal software in an IT organization where external exposure is not a big concern.
- Best: Fully integrated into pipeline – This most-stringent but strongest option ensures your code base has an established baseline of secure practices applied to every code check-in from the beginning throughout the lifetime of a project.
Hopefully this short article has provided insight into how security can be integrated directly into your development stream–in a way that provides benefits quickly with low friction and cost. For even more examples and strategies, reach out to Polaris and take a look at the services GitHub is now providing to customers with strong security concerns.
See DevSecOps in GitHub.
Back to Blog