Introduction to Secure Software Development Lifecycle

Many of you will be familiar with the software development lifecycle (SDLC) as a representation of the different stages of software development from planning and design through to support - illustrated in the diagram below.

When we consider what formal security actions take place throughout those phases, traditionally, the penetration test comes to mind as the pre-production validation step that the solution is secure. However, whilst it remains important, it should be viewed as another piece of security assurance, rather than a catch-all for any security related issues. DevOps adds a demand to shift-left and introduce security activities earlier in the SDLC for the purposes of efficiency and avoiding last minute re-development. There is however, now growing expectation that software manufacturers carry a burden of responsibility for the ensuring their products are delivered secure, this principle is encapsulated in Secure-by-Design.

Secure-by-design

Secure-by-Design, or security by design, is a principle that integrates cybersecurity into all aspects of the development lifecycle, right from the start.

Its used to highlight how a burden of responsibility should fall on software manufacturers to ensure that the software they create is secure, by design and default. The US Cybersecurity and Infrastructure Security Agency (CISA), alongside other agencies including the UK National Cyber Security Centre (NCSC) established the following three core principles in 2023 (link below):

• Take ownership of customer security outcomes and evolve products accordingly.
• Embrace radical transparency and accountability.
• Build organizational structure and leadership to achieve these goals.

The reasoning behind this comes from efforts to reduce the number of vulnerable applications released to market, but also to help reduce the risk of vulnerabilities within the supply chain. Not all aspects of these principles are directly relevant to Storm ID, however several of the themes can be found in frameworks and principles directly relevant to us and our clients. For example, the Scot Gov Cloud First principles, the NCSC Cyber Assessment Framework, and the UK Gov Secure by Design principles all include aspects of these principles. The expectation from clients, particularly those associated with Government, is that suppliers such as us have a clearly defined approach to security at all stages of Software Development and this is what we are trying to define via a Secure SDLC.

Secure Development at Storm

Our approach to secure software development, ensuring software is secure by design, is outlined in our secure development policy. The details of the SSDLC will further expand on these, describing how we apply those policy objectives to develop software securely.

The following are some examples of the security activities we look to include in software development projects:

• Threat Modelling: At the design stage, we employ Threat Modelling to analyse systems or components and make important security-related architectural decisions, based on the intended use and operating environment of the system.
• Software Composition Analysis (SCA): We can identify vulnerabilities in the components used in our software, which could compromise the application. Through SCA, we scan dependencies for vulnerabilities and generate a Software Bill of Materials (SBOM), which helps manage an inventory of the application over time.
• Static Application Security Testing (SAST): When writing code, we perform SAST to look for known bad or insecure patterns and scan for secrets.
• Dynamic Application Security Testing (DAST): In a test environment, we use DAST with templates to confirm the security posture meets our internal standards and those of our clients.
• Vulnerability Management: All findings are streamed to a central location for analysis, management, and reporting. Centralising this information allows us to measure our success and helps meet some of our compliance requirements, including those set by ISO 27001.

As an example, the diagram below shows where these may sit in the SDLC.

In this post we’ve looked at what a Secure SDLC is, why it’s relevant to Storm ID and our clients. If you have any feedback on the content here or would like to see more information on a particular security topic please get in touch.