The “S” in SDLC: System, Software, or Security?

This article explains Strike Graph’s take on what the “S” stands for in SDLC along with useful templates.

Written By Micah

The “S” in SDLC means different things to different organizations and even different IT security frameworks.

Software Development Lifecycle (aka Software Development Policy)

Strike Graph refers to this as Software Development Policy (remove the “Lifecycle”) and we offer this template as a resource to all customers. Our template outlines the steps in a typical software development process, required controls, and different coding standards that may be applicable to various organizations. It also describes common secure coding standards. These standards can be added to or removed, based on what makes sense to your organization.

Some companies choose to integrate the concepts within this template into an overarching Change Management Policy that covers both systems and application changes, while others find it helpful to keep system change policies and procedures separate from software (or code) change policies and procedures.

System Development Lifecycle (aka Change Management Policy)

At Strike Graph we have built our Change Management template to include steps of a typical System Development Lifecycle Policy. Our Change Management template describes how changes to systems (i.e. the network or supporting service) are handled, how to classify or categorize changes, and what controls are expected to be present. This template is available to all Strike Graph customers and includes specific content callouts for our PCI customers.

For our NIST 800-171/CMMC customers, we suggest renaming the Change Management Policy template to the System Development Lifecycle Policy to align it more closely with the NIST framework.

Our template may include software development language, and if this is something your organization does not do, you can remove it from the template. For example, it includes very specific software development language required by the PCI-DSS. The PCI ‘secure coding’ language is appropriate for any organization, and if you do create your own code, we suggest adopting PCI secure software development concepts, if you are able.

Secure System Development Lifecycle (S-SDLC)

Strike Graph offers the Secure System Development Lifecycle policy template to our ISO 27000 and PCI customers. It is a high-level document that describes security activities in each phase of a system’s development and can be tailored to your organization.

The ISO 27002:2022 framework specifically calls out the Secure Development Lifecycle (Annex control 8.25), principles for engineering secure systems (8.27), and secure coding principles (8.28).

PCI requires the development and maintenance of secure systems and applications that includes guidance on testing for common vulnerabilities in software development, such as cryptographic storage, communications, and error handling.

Questions?

Reach out through our chat feature for real-time Customer Success support 8 am - 5 pm PT Monday through Friday.