What Does "Sec" Stand for in DevSecOps?
The “Sec” in DevSecOps stands for security. Right now, you might be tilting your head and pondering why such an obvious statement must be said. Pull out your team’s Definition of Done and highlight where cybersecurity concerns are captured. DevSecOps is intended to represent that cybersecurity is smartly shifted left, so far left that cybersecurity aspects should be considered in the context of every software development activity.
Let’s return to that Definition of Done. Many will point to a bullet that simply reads “NFRs met” and state cybersecurity occurs right there. However, that is misaligned with the actual intent of expanding DevOps to DevSecOps. Why? Cyber threats are too pervasive and too advanced to mitigate business risk by reducing cybersecurity activities within the CI/CD pipeline to an opaque non-functional requirement bullet.
As Software as a Service (SaaS) took hold circa 2000 and service level agreements created a financial stimulus for software providers to avoid those ugly “This service will be offline this weekend for a planned upgrade” email, IT was pressed by the business to keep the software online. Suddenly, “keep the software online” was such a pervasive problem that it was no longer a non-functional requirement; it became a compelling change agent. It was a compelling change agent because according to Atlassian’s History of DevOps page, “The DevOps movement started to coalesce sometime between 2007 and 2008, when IT operations and software development communities raised concerns [about] what they felt was a fatal level of dysfunction in the industry.” Fatal level of dysfunction! The most obvious of all non-functional requirements, that the software sold should actually be online and available to use, was so maligned with reality that an entire industry pivoted.
It took the aughts to mature and weave SaaS into the fabric of the web, and it took the teens to mature DevOps and address the “fatal level of dysfunction” between IT Operations and Software Development. Now, here we are in 2023, and society cannot go more than a couple of days without a new dramatic headline describing the latest impact of a cyberattack. Businesses are spending inordinate amounts of money on cyber insurance and compliance activities, yet neither of these have created an acceptable level of residual risk. Every critical infrastructure sector is buckling under the weight of cyberattack risk, including hospitals. We can now say with a straight face that software is creating a fatal level of risk to human life.
As developers, it took a declaration of a fatal level of dysfunction to inspire us to expand our horizons and change the way we develop and deploy our software. As a community, we came together to do what we do best – we designed new capabilities, we built powerful CI/CD pipelines, we automated to manage drift and reduce deployment friction, and we employed ChatOps to ensure the whole team knew when a build failed or when there was a performance problem in production.
October 1 marked the start of Cybersecurity Awareness Month. We are 2 years and 9 months into the current decade that started on January 1, 2021 (at least according to the US Naval Observatory and the Farmer’s Almanac!). Our industry touts DevSecOps at conferences, it shows up in software developer resumes, and it is commonly found in RFPs. Yet development teams generally still fail to meaningfully actualize the “Sec” in DevSecOps and must be reminded that it stands for security.
This isn’t just a perception problem. The SANS 2023 DevSecOps Survey, published in August 2023, offered a statistically significant and sobering summary of the state of “Sec” in DevSecOps:
“Across the spectrum of options, security testing is down overall, with a marginal increase in security unit testing. The emphasis on security testing prior to coding— architecture/design and requirements/use cases—that was seen in 2022 has declined sharply this year, and testing while coding via integrated development environment (IDE) plug-ins has declined, as well... Additionally, in nearly every category, fewer respondents indicated that they perform security testing in each phase of the build and release pipeline workflow.”
No one can anticipate when/if the software industry has reached the tipping point where there is a true coalesce between DevOps and cybersecurity teams. Interpreting the current data, it would seem the average software developer still hasn’t come to grips with the fact they literally are the front lines of cyber. The threat of government regulation is driving more conversation and action than the software and InfoSec communities are having between themselves. To illustrate, the Federal government definitively spurred the current wave of interest and activity associated with software bill of materials (SBOMs) and Vulnerability Exploitability eXchange (VEX) documentation.
Businesses and their shareholders still choose time to market over solution resiliency, and that does not have to change. The introduction of NIST SP 800-218, Secure Software Development Framework (SSDF), shows the promise of helping businesses realize and convey to the market a solution’s level of resiliency. The SSDF showcases that market forces can evaluate software acquisitions using a three-axis model: functional experience and user experience, which are well understood, and on a new third axis a security experience. Businesses and consumers should be afforded the opportunity to select a product with a level of cyber resiliency they are comfortable with and can afford, but that cannot happen if businesses don’t transparently share the product’s security experience characteristics. It also cannot happen if development teams don’t expressly act on the “Sec” in DevSecOps consistently.
In the near term, in recognition of Cybersecurity Awareness month, come together as a team to review how your team is actualizing cybersecurity. The SANS DevSecOps Survey highlighted the usefulness of various security testing practices and tools. The top five included:
- Perform risk assessments before development starts
- Automated scanning of code for security vulnerabilities and other defects
- Penetration testing
- Security training
- Threat modeling or attack surface analysis
Neither an Agile mindset nor adoption of an Agile framework alone helps teams realize these activities. Addressing the cybersecurity challenge will require development teams to expand their skillset and become more conversant with terms that include residual risk, security control, and governance activity. Start by reviewing your team’s Definition of Done and discuss how to pivot cybersecurity out of the catch-all non-functional requirement bullet into something transparently crisp. Encourage your leadership teams to enroll in training so they too are part of the journey towards delivering more resilient software solutions. Expand your reporting using a “both/and” mentality, adding in new cybersecurity KPIs.
Together, DevOps and InfoSec teams can successfully combine to form powerful DevSecOps teams, just as IT Operations and Development teams were successful over the last decade to form successful DevOps teams. It won’t happen overnight, and it won’t happen by accident, but together we can help create compelling security experiences that embody the true intent of practicing DevSecOps.
