Implementing a DevOps pipeline is all about having developers and operations work closely together. Security controls should not be something that operations—or worse, a security team—adds to the infrastructure. Instead, it should be part of the software product that is carried from design through development and pushed live at operations.
"Security as code" is one of the main themes at DevSecCon London, which runs Oct. 19-20. Finding ways to treat security controls in the same way as other code requirements is key to integrating security into the development process, said Francois Raynaud, founder and managing director of DevSecCon.
"Security as code is really about making security more transparent, to work with developers and speak the same language. We really need to give them the tools and the security policies so they know what to do and can do it themselves."
—Francois Raynaud
Security as code is one of the three main ways of integrating security into the DevOps process. The concept guides development and security teams, espousing the ideal of integrating security into the product at the time of development and making developers responsible for thinking about operations.
Here is a rundown on the state of security as code, and other key concepts that speakers will cover at DevSecCon.
Create security champions
Companies should also focus on creating security champions—developers who are focused on security, who can spot incidents where the need for security is exemplified, and who can teach other developers about security concepts.
Continuous testing should be used to regularly check code as it moves through development to deployment and even after it is live, to make sure that deployed services are free of known vulnerabilities, weaknesses, and misconfigurations.
Renaud notes that Equifax missed fixing an out-of-date product—leading to its massive loss of the credit records of 143 million Americans—was a perfect example of what happens when security is overlooked.
"With Equifax, they failed to recognize that they needed to apply a patch. That's unbelievable but—we have to admit—all too common."
—Francois Raynaud
Make adequate checks a mandate
The automated nature of integrating security into DevOps can represent a danger if it is done incorrectly and without enough checks built into the process. Developers have often included hard-coded secrets, known as API keys, in their software, and then automation takes over, publishing the security information to GitHub as part of the development process. In other cases, developers have made Amazon S3 storage buckets accessible to the world, leading to a data breach.
With DevOps, you have a lot more people who are involved in the development pipeline, said Mike Shema, vice president of security operations and research at the crowdsourced security provider Cobalt.io.
"Ideally, you can have quicker reaction to security notices, but there are a lot more fingers on the pipeline, so you have to make sure that security as code also has more checks on data and secrets."
—Mike Shema
Automation also adds danger to the DevOps process if not continuously checked. Security teams should always ensure that automation fails gracefully—for example, by staging the rollout of any new code, so that if there are problems, the issues do not take down the entire infrastructure.
"We need to set up good feedback loops," says Shema, who will be presenting at DevSecCon London. "What we will do is set up some post-mortem and look at why the flaw happened, then find a way to fix the process."
Another benefit of security as code: When developers learn new lessons, they can incorporate their experiences into the security code and share the knowledge easily.
Encode your deployment policies
When security-as-code expert Fraser Scott wanted to add security checks to an existing agile development process, he knew he could not do it in a way that blocked productivity. Instead, Scott had developers write their deployment specifications in the popular YAML data-as-text format. The team then checked those specifications with an automated security system before deploying the application to the cloud.
The result: If the code passed every check, it could be live in six minutes.
"This is literally security as code. We are not blacklisting bad things. We are saying that these are the acceptable guardrails, and as long as your code fits into these existing guardrails, it will be deployed."
—Fraser Scott
To help DevOps developers and security managers create the appropriate security policies to incorporate into their pipeline, security-as-code expert Scott will present details of the OWASP Cloud Security project at DevSecCon London. The project's goal was to create encoded deployment policies.
"If you want to use a particular service, you may know how to do it technically but are worried about the security aspects. This will be like a library of threats you can test your environment against."
—Fraser Scott
Security as code is key, but not the only goal
DevSecCon's Renaud cautions developers and security teams to not take the security-as-code concept too far, however. The idea fits into DevOps as part of the proper way to do security, but it should not be considered the ultimate security goal, he says.
"Thinking of security as code as the only consideration may mean you are oversimplifying. It is certainly one of the big pillars, [but security] is really a complex matter."
—Francois Renaud
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
