DevSecOps Is not Optional Anymore

Most organizations are practicing some sort of DevOps these days. Some are achieving amazing release velocity, particularly if they have a continuous integration/continuous delivery (CI/CD) pipeline set up. However, even the average consumer can tell that release velocity is not always accompanied by higher application quality. Yet, the whole point of Agile, DevOps and CI/CI is to produce better quality code faster.

One important quality issue, which is relatively new, is application security (at least when compared to unit testing, for example). Performing a vulnerability check late in the software development lifecycle (SDLC) is woefully inadequate which is why "shift left" quality practices have been embraced. Shift left, if you are unfamiliar with the term, means making developers more responsible for the quality of their code than they have traditionally. The practice involves all kinds of testing including performance testing and security testing. However, fundamentally what companies need to do is to bake security into code more comprehensively.

Creating more secure code is difficult to do when DevOps and Security are working in silos because it slows down release cycles and they do not have the benefit of a common language or a common set of practices. Given the growing number and types of cyber security threats, DevOps teams are increasingly morphing into DevSecOps teams because their companies need to produce secure code. 

Taking an SDLC approach to security

For more than two decades, software teams have been advised to "test early and often" if they want to improve the quality of their software. What was intended by the statement is test throughout the SDLC because that's the best way to ensure product quality.

As the result of cross-functional Agile and DevOps practices, developers, testers and ITOps now understand that quality isn't a stop along the journey, it's part of the journey. 

Security is a relatively new development (compared to unit testing, for example) thanks to the growing number of cyberattacks. Achieving adequate application security requires someone from the security team to play an active role on the DevSecOps team so that security can be designed into every phase of the SDLC. The point of that is to catch vulnerabilities as early as possible because they're faster and cheaper to fix than later in the lifecycle. More importantly, the number of application vulnerabilities can be reduced when people with different roles have an opportunity to catch them – designers, developers, testers, QA engineers, security professionals, and ITOps engineers. Of course, tooling exists to help facilitate all this, but tools alone don't equate to an effective DevSecOps practice.

Accountability is "a thing"

Particularly with the rise of AI, there is more discussion about AI ethics, digital ethics and tech ethics. Part of that has to do with responsibility and accountability. When something goes wrong, whom should be held responsible? The creator? The user? The component provider? The person who authorized the purchase? It is not an easy question to answer.

A similar trend has already unfolded at the software project management level and there is already a framework for making it happen. It has called the RACI matrix that defines and documents project roles and responsibilities.

RACI stands for responsible, accountable, consulted and informed, each of which is a stakeholder's role.  Specifically, "responsible" people doing something or authorizing something. "Accountable" people own the project. "Consulted" people are those whose input must be included. "Informed" people just need to be kept in the loop.

RACI matrices are actually structured as a table. Rows are associated with a specific task, decision or milestone. Columns include the various tasks associated with a project, from left to right, are the tasks included in a project, the name of the stakeholder, the stakeholder's professional roles (project sponsor, business analyst, project manager, technical architect and application developer). The cells underneath each professional role include the RACI role designation of R, A, C, or I, depending on what the individual's role will be concerning a specific task.

The beauty of RACI matrices is that they help project teams communicate more effectively and avoid all the friction caused by failing to understand what each individual should be doing. When it comes to cyber security, achieving this sort of clarity is essential.

Supply chain liability requires SCA, SBOMs

Today's applications contain more third-party software components, libraries and APIs than ever before. Some of them are open source and some of them are commercial products. As a result, a company may be held liable for software it did not even create. That is why software composition analysis (SCA) software is so critical. It is also advisable to have a software bill of materials (SBOM) which is a living document of the components used in an application, where they came from, their dependencies, known vulnerabilities, versions, etc. 

Both SCA and SBOMs should be included in a DevSecOps pipeline. The SBOM can be created and maintained in an automated fashion which is necessary given the complexity of today's software. That way, if there is an audit following a security incident, both the SCA and SBOM will make the production of evidence that much easier.