Organizations are focused on releasing software faster to stay ahead of the competition. Software development processes have become more flexible, push functionality out more often and in smaller chunks. In other words, organizations have adopted lean and agile principles across the software development lifecycle to move at a faster clip. But this alone wasn’t enough to move at the pace required. In order to bridge the gap between software development and the actual production operations of the code, a new approach was necessary: DevOps; a shifting left of operations. This shift left of operations towards the developer made good sense but left a huge gap to be addressed: security.
Security teams cannot keep up with development processes and do an effective job while being on the outside of these new DevOps processes. Fortunately, there have been significant efforts the last few years to re-imagine how security can better integrate into the software development lifecycle.
Enter DevSecOps, where the build, test, and release aspects of the DevOps cycle have security considerations built into them. These considerations are part cultural, part training — including specifications or policies — and part vetting of security components.
Want to take a deeper dive? Watch our on-demand webinar, Inject Security Into Source Code: How 2018 Will Shift Your Application Security Priorities.
The DevSecOps philosophy is that security should be embraced and made better by everyone within the organization and also be supported by those with the skills to contribute security value to the system. Security practices have to move at the speed of the rest of development. Developers must resolve common open source issues earlier in the software development life cycle, decreasing costs and speeding time to market. This means security considerations are moved up front, shifted-left as much as possible to the developer. In other words, security is baked into the development process.
But does this mean that security is shifted entirely onto the already heavily loaded shoulders of the developer? Of course not. Security is all about protection in depth, from the edge of the network down through the application to the data layers, operating systems, and the people involved. However, it does mean that developers need the tools that can help automate and bake in as much security as possible. Ideally, baking in security at the time the code is written and of particular note, when architectural decisions are being made.
Here are four things developers can do to bake security into their products:
- Understand your company’s security policies and security standards so that security components can be chosen wisely at development time
- Implement build environments that are static, reproducible, and immutable. Trusted & curated language distributions can enable these benefits across the entire team. All machine/container images should be reviewed and have parity to what is in production. This includes the continuous integration systems that run your test suites.
- Be proactive. All third-party open source components should be scanned for license compliance and vulnerabilities and these should be known during development, not after.
- Use the latest versions of components and from projects that are actively maintained, where possible.
Operations can also help shift security left with a “defense in depth” approach. They should also be able to verify that components running in production can be proven to actually be the ones running.
The onus of baking security in is not necessarily on the developer. The responsibility on the developer is making security a standard consideration during development. The automating of vulnerability checking, license compliance, and component update checks…it’s all table stakes. Having these security and compliance pieces automated is the only way your security can move at the speed of the entire software delivery pipeline.
Want to take a deeper dive? Watch our on-demand webinar, Inject Security Into Source Code: How 2018 Will Shift Your Application Security Priorities.
