These best practices can help you deliver on the potential of true DevSecOps.
Software development has been supercharged by DevOps. By integrating development, testing, deployment, and release cycles into a single collaborative process, DevOps has enabled developers to bring applications online faster than ever.
As is the case with most technology developments, however, security took a backseat to business exigencies as DevOps evolved. That's changed with the emergence of DevSecOps, which promotes integrating security throughout the software development lifecycle.
But implementing a DevSecOps program requires intelligence, situational awareness, and collaboration. These five best practices, shared by top practitioners, can help your software team meet the requirements of modern DevSecOps to deliver security at the speed of today's software.
1. Start early — and start small
The earlier in the development process security activities are integrated into the software development process, the earlier defects can be detected and corrected, says Casey Bisson, head of product and developer relations at BluBracket, a cybersecurity services company.
"The biggest benefit of DevSecOps is shaping security requirements earlier in the software development lifecycle. When this happens early enough — at the design and architecture stage — it’s a boon to developers and their security outcomes."
—Casey Bisson
When combined with more automation, DevSecOps can save developer time — and increase their velocity.
However, it isn't wise to go hog wild and start deploying too many rule sets and scan configurations when launching a DevSecOps program. That can create a sudden explosion of security findings in your developers' queues that they don't have time to address. Not only does that mean flaws won't be fixed, but it also undermines developer support for the process.
Security testing should be introduced gradually. It also makes sense to limit the size of the rule sets used initially so when flaws are found, developers have time to fix them. As security is integrated further "right" in the development process, deeper scans and reviews, such as for software supply chain attacks including dependency confusion attacks targeting NPM repos, can be included in the process for greater prerelease security assurance.
"Poorly implemented DevSecOps and shift-left strategies backfire because they don’t go far enough, and instead simply add more hurdles for developers without giving them the support they need. When developers face hurdles to progress, they will engineer workarounds, and that can lead to less secure results."
—Casey Bisson
2. Perform threat modeling
Before any code is written, the shape of a DevSecOps program should be determined through threat modeling and architectural reviews, said Caroline Wong, Chief Strategy Officer at Cobalt Labs, a penetration testing company. A valuable asset for threat modelers is an inventory of digital assets, such as a Software Bill of Materials, or SBOM.
"Threat modeling is the process of thinking through any-and-every-thing that could possibly go wrong, and then implementing a plan to prevent the worst from happening. Know your digital assets. That's a simple way of saying keep your SBOM up to [date.]"
—Caroline Wong
Wong said that the term SBOM was sort of silly, noting, "It sounds much scarier than it is."
The bottom line, she said, is that you can’t secure what you’re not tracking.
3. Use DevSecOps to bake privacy into apps
DevSecOps should bake in privacy concerns into every stage of an application's development, to prevent any secrets such as credentials or personal identifying information (PII) from making it into their developers' code before it is released.
"DevSecOps teams should scan code both within company repositories and outside in public repos, on GitHub for instance. It's so easy to clone code that these details and secrets can easily be leaked."
—Casey Bisson
Bisson explained that applications have loads of personal data that need to be protected.
"There have been far too many examples of leaks of PII within code, for instance, because many organizations don't secure their GitHub repositories."
—Casey Bisson
John Bambenek, principle threat hunter at Netenrich, an IT and digital security operations company, said secrets protection was critical given the way software is developed today, drawing upon public repositories and using open source.
"Data protection should be embedded in the development process to ensure that data is used safely and that the entire development pipeline is informed with strong privacy principles."
—John Bambenek
4. Automate as much of the DevSecOps process as possible
The only way DevSecOps can keep pace with DevOps-empowered developers is to automate its security tools and processes. In addition to allowing security to keep pace with development, automation can ensure that DevSecOps tools and processes are used in a consistent, repeatable, and reliable way.
As valuable as automation is to DevOps, it's important to recognize that not all security processes can be automated. Wong pointed out that automated security testing cannot cover business logic flaws, race conditions, or software supply chain exploits. Neither can it perform penetration testing, nor do threat modeling.
While these manual tasks can affect the time it takes to complete a project, they can be moderated through the use of "triggers." For example, source code analysis or deeper binary analysis may need to be done only when an automated scan exposes anomalous results, or a pen test may need to be done only when a critical vulnerability is found in a third-party software component. By triggering manual processes only when necessary, the time spent doing them can be reduced.
5. Guard access to your software development environment
With teams collaborating more openly with each other, it's more important than ever to know who is doing what in a development environment, explained Hank Schless, senior manager for security solutions at Lookout, a provider of mobile phishing solutions.
"Cloud-based SaaS apps enable high productivity in the development process, but could also introduce risk if not properly secured. Most importantly, you want to ensure that your privileged user accounts are monitored and any anomalous behavior is detectable."
—Hank Schless
Schless noted that tools like user and entity behavior analytics (UEBA) can help you detect whether any employees are interacting with services, apps, or data in ways that they shouldn’t be, which could indicated a compromised account.
Organizations can get a handle on controlling access within their environments through the use of least-privilege principles and role-based access. Least-privilege means granting employees only the permissions they need to perform their jobs and nothing more.
Role-based access ties a person's permission to their role. Someone in a developer's role, for example, might have access to an organization's code repositories, while someone in a tester's role might have access to an organization's staging environment.
Do DevSecOps right, or face the consequences
Embracing modern best practices for a DevSecOps program will ensure that it's done right. That's critical because given the rise of software supply chain security, a defective program can undermine the very thing it was created to bolster.
"DevSecOps is often an illusion that means little more than giving developers admin privileges and then being shocked when security failures occur."
—John Bambenek
Automated testing, good privacy hygiene and access controls are requirements, but software security assurance tools that offer code analysis, and deeper binary analysis of compiled code, can ensure that newer software supply chain attacks like SolarWinds, Log4j, and most recently IconBurst, are kept at bay.
All Stories
Software Supply Chain Security
Dev & DevSecOps
CI/CD Security
Container Security