In the current era of cybersecurity threats and the consequentiality of exploited vulnerabilities, security cannot play second fiddle to other priorities during the software lifecycle.
In the race to be first-to-market with new and innovative products, many organizations that rely on legacy and traditional software development models push security considerations and compliance to the back burner, testing for vulnerabilities as a hurried last step when business pressures to get to market can be most intense.
This approach, however, is self-defeating. Waiting to find and fix security flaws until a piece of software is considered “done” can—and does—lead to one of two problematic outcomes: either the software deployment is delayed when vulnerabilities are inevitably identified, or it is shipped out as is, security flaws and all. This disconnect between process and desired outcomes has grown especially pronounced as organizations deploy software with increasing frequency. According to one 2020 survey, 55% of global software developers say their teams deploy to production at least once a week, making ad hoc or delayed security testing both unsustainable and inefficient.
This is where DevSecOps steps in. Building on the DevOps approach, which closely integrates software development processes and personnel with information technology (IT) operations, organizations using a DevSecOps framework add security testing and coordination to all phases of the software lifecycle. This starts at the very beginning of the build process, rather than saving vulnerability tests for the final software review stages (or skipping out on them altogether).
Adopting a “secure by design” approach—not as an afterthought but as a foundational principle—rests on the concepts of Continuous Integration and Continuous Delivery (CI/CD), which “encourage and support frequent code check-in, version control, […and] continuous low-risk releases and feedback,” according to an explainer from the General Services Administration (GSA).
Zooming out to look at the bigger picture, DevSecOps brings several overarching yet interconnected benefits to organizations that adopt the process and culture shift:
The above benefits provide value for any organization, no matter its shape or size. However, the advantages are even more clear cut for the national security community, including federal agencies and the companies that partner with them.
Think about it. It’s risky enough to provide potentially insecure software to commercial businesses or individual consumers. The consequences of doing the same for the code and containers that contain classified information and underpin war-fighting functions would be dire. It comes as little surprise, then, that the Department of Defense (DoD) is leading the charge in federal government adoption of DevSecOps, though government efforts remain generally less mature than commercial industry (where they have become widely adopted best practice). As evidence of this ongoing process and culture shift, DoD launched Platform One—its enterprise-level DevSecOps managed service—in early 2020 with the mission of accelerating secure software delivery across the Department. The platform offers CI/CD pipelines, tooling, custom development services, and more in an effort to encourage wider DevSecOps adoption.
There are several types of tools gaining traction as more organizations, both public and private, turn to DevSecOps. Some—like those that perform open source vulnerability scanning and software composition analysis, container/image scanning, static and dynamic application security testing, and data loss prevention—are focused on helping developers continuously identify and root out vulnerabilities. Others help teams automate and monitor the underlying infrastructure, not only to counteract security risks but misconfigurations too. In addition, tools that provide DevSecOps teams with oversight and actionable insight into the process are key. Configurable dashboards, visualization tools, alert systems, and threat models all serve this purpose, enhancing collaboration and shared awareness.
Many of the above tool types involve automation, a key pillar of any successful DevSecOps workflow. By minimizing the need for human intervention across the different stages of the software lifecycle—from development and quality assurance to staging and production—organizations can save time and instill transparency, auditability, repeatability, and the capacity for rapid iteration, as highlighted by 18F (an office within GSA dedicated to helping government agencies build and buy innovative technology). In particular, as organizations’ DevSecOps practices mature, they should lean towards tools that provide automated insight into deployment frequency, application recovery rates, issue resolution times, and vulnerability patching times, among other “high-value” metrics, according to another guide by the GSA.
Whether you sit in a government agency or a commercial company, the key takeaway here is inescapable: in the current era of cybersecurity threats and the consequentiality of exploited vulnerabilities, security cannot play second fiddle to other priorities during the software lifecycle. The stakes are simply too high, and bad actors far too willing and able to exploit weaknesses, if given the opportunity. So while software security is never guaranteed, adopting a DevSecOps framework, properly trained and equipped with tools and resources, minimizes such opportunity, all while capitalizing on the very traits that have made the software industry successful in the first place—constant iteration and innovation.