NCCoE DevSecOps Workshop

A software development life cycle (SDLC) is a formal or informal methodology for designing, creating, and maintaining software (including code built into hardware). There are many models for SDLCs, including waterfall, spiral, agile, and – in particular – agile combined with software development and IT operations (DevOps) practices. Few SDLC models explicitly address software security in detail, so secure software development practices usually need to be added to and integrated into each SDLC model. Regardless of which SDLC model is used, secure software development practices should be integrated throughout it for three reasons: to reduce the number of vulnerabilities in released software, to reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and to address the root causes of vulnerabilities to prevent recurrences. Vulnerabilities include not just bugs caused by coding flaws, but also weaknesses caused by security configuration settings, incorrect trust assumptions, and outdated or incorrect risk analysis.

Most aspects of security can be addressed at multiple places within an SDLC, typically with some differences in cost, effectiveness, and ease of integration. However, in general, the earlier in the SDLC that security is addressed, the less effort and cost is ultimately required to achieve the same level of security. This principle, known as shifting left, is critically important regardless of the SDLC model. Shifting left minimizes any technical debt that would require remediating early security flaws late in development or after the software is in production. Shifting left can also result in software with stronger security.

With today’s software, the responsibility for implementing security practices is often distributed among multiple organizations based on the delivery mechanism (e.g., infrastructure as a service, software as a service, platform as a service, container as a service, serverless). In these situations, it likely follows a shared responsibility model involving the platform/service providers and the tenant organization that is consuming those platforms/services. Another aspect of today’s software is that it often uses one or more software components developed by other organizations. Some of those components may also use components from other organizations, and so on. Managing cybersecurity risk from third-party software components, as part of C-SCRM, involves identifying, assessing, selecting, and implementing processes and mitigating controls. This risk management can largely be integrated into DevSecOps through its automation capabilities.

For more information: devsecops-nist@nist.gov