Securing the Software Development Lifecycle (SSDLC)

Today's organizations continuously create new products and features in addition to performance and security improvements. They look to develop and rely on a software development lifecycle (SDLC) to bring an element of consistency and reliability to their delivery process. The software development lifecycle begins on an engineer’s local machine. It then proceeds through CI, where it’s built, tested, and finally deployed on your target infrastructure, where alerting and monitoring tooling looks to identify defects and performance issues whose resolution may help to improve user's product experience.

The software development process naturally relies on many 3rd party dependencies, including application packages, runtime infrastructure, tooling, and SaaS applications. This allows development teams to iterate quickly without having to recreate the wheel. However, a significant part of this development process is the security of the product you’re developing. At each stage of the development lifecycle is an opportunity to improve your product's overall security by identifying security issues, vulnerabilities, and compliance gaps to help maintain your business continuity and improve sales enablement.

This article will cover the secure software development lifecycle (SSDLC), its integration within the SDLC, where the greatest value can be found, the tooling to support you, and how it fits into your security strategy.

The secure software development lifecycle is a concept that focuses on introducing security principles, such as defense in depth, control governance, security architecture, and risk management in the software delivery model. Well developed SSDLCs are focused on improving your organization’s security posture through the SDLC without impacting the developed experience (DX).

The SDLC represents software design, development, testing, deployment, and monitoring. It encompasses all the stages involved in creating a software artifact, whether a mobile application, SaaS, PaaS, or binary. Naturally, the SDLC for each provided example is different, and each flavor brings its own challenges along the way.

The SSDLC focuses explicitly on implementing and monitoring security controls that control how your product transitions across SDLC phases while ensuring that it meets the security expectations of your organization, customers, and regulators. Various concepts are integrated into the SSDLC, depending on where they’re required:

• Threat Modeling: Threat modeling is a security process that occurs during the software requirements gathering and design stage to identify security threats, the risks they introduce, compensating controls to mitigate the risks, or alternative solutions to avoid the risks entirely. In a previous article, we covered the various threat modeling frameworks and methodologies you can use to improve your product's design security.

• Supply Chain Security: A significant portion of your attack surface is comprised of your application and infrastructure dependencies, in addition these dependencies tend to be open source, more often than not. However, open-source does not mean "more secure" and does come with its own risks. Vulnerabilities like Log4J demonstrated the downsides of relying too heavily on open-source software. Automated dependency scanners are powerful tools to leverage here, alongside auto-remediation functionality.

• Penetration Testing: Not all vulnerabilities can be identified through automated scanners and analyzers. Applications often contain complex bespoke logic that can contain intricate vulnerabilities whose identification requires an understanding of the product’s core functionality, role authorization model, authentication methods, and sensitive functions. Penetration testing is a key security process that must be leveraged as part of any mature SSDLC.

• Security Operations: Security operations teams require relevant logs to be produced and transported to the correct log ingestors to enable incident alerting and monitoring tooling. Determining which logs to produce and how to structure them is a key part of the design process and can improve the effectiveness of the security incident response function.

Over the past decade, the cybersecurity space has been flooded with terms defining various overlapping concepts. This can make navigating the field confusing and difficult for experts and novices alike. Two of these concepts are “application security” and DevSecOps. While they reside comfortably within the SSDLC, they differ and overlap with their objectives and methodologies.

Application security is generally focused on securing your applications, not the security of your application’s infrastructure or the network used to support or access it. Additionally, it’s rarely concerned with security controls that can be implemented once an application has been deployed. In the context of a SaaS application, security incident response falls outside the scope of Application Security. For example, if your application is deployed on AWS, controls such as IaC security scanning, Cloud Security Posture Management (CSPM), HSM configurations and access, etc., are often considered out of scope.

DevSecOps is now a commonplace term and is an approach to developing a secure software development lifecycle. Unlike Application Security, it has a broader scope; it leverages DevOps concepts, such as continuous integration, continuous delivery and deployment, GitOps, etc., to implement and ensure security controls across the SDLC. With DevSecOps, we look to integrate security controls into our pipelines and leverage automation as much as possible. This includes solutions such as automated and AI-assisted threat modeling, SAST, SCA, DAST, and penetration testing, to name a few.

Security should be included in your SDLC, which can be an iterative process. Changes to the SDLC should always be made with caution, and engineer feedback should be a continuous element of the process. Your engineers are the primary customers of the SDLC, and given that the SDLC is the most important component of your product’s delivery, it’s vital to ensure that it’s reliable, easy to use, understand, and debug.

Before securing your SDLC, you must understand how it’s implemented and how your engineers leverage it. Each artifact produced by your SDLC has distinct stages that you and your engineering functions have determined relevant to your product. Modifications to your SDLC can directly affect the release process, and there are several elements you should consider before suggesting or making some changes. For example, some of the questions you could ask are: what is the product? Is it a SaaS, mobile or desktop application, a binary or container image, or a combination of all? What tools and infrastructure are used for building, testing, and deploying your product? Is your release process on a fixed schedule or continuously deployed?

Once you feel you’ve thoroughly understood your development lifecycle, it’s time to determine its different stages. The development of a product starts at the design stage and proceeds through to development, build, testing, and deployment. How and where these stages are accomplished, as well as their “Definitions of Done,” are key aspects of the SDLC that are also highly important from a security perspective. Each stage of the development process is an opportunity to consider and evaluate the product’s security posture at that stage. For example, threat modeling is a standard process used during the design stage, and static source code analysis is used across the build and testing stages, with penetration testing often used as part of the deployment stage.

As you can see, understanding your SDLC has helped you identify opportunities to implement security controls that can help provide higher reliability in your product's security and control governance and compliance.

Introducing security into your SDLC is a significant shift in the standard operating procedure. As a result, it can be challenging if introduced in a rush or without due consideration for the current DX and Key Performance Indicators (KPIs). Therefore, you should identify iterative maturity levels that you can use as stepping stones to introduce security into the SDLC.

SAMM offers the following maturity levels:

• Level 0 - Incomplete: No security practices are in place, or they are ad hoc and unorganized.

• Level 1 - Performed: Basic security practices are performed, but they may be inconsistent or informal.

• Level 2 - Managed: Security practices are planned and executed according to policy.

• Level 3 - Defined: Security standards are defined and implemented across the organization.

• Level 4 - Measured: Detailed metrics are collected to measure the effectiveness of security practices.

• Level 5 - Optimizing: Focus is on continuous improvement of security practices based on metrics and feedback.

As more information comes to light through visibility and best efforts remediation activities, it can help guide enforcement and determine the KPIs you should measure and optimize. Every organization is different, and so are its problems and challenges. You should identify what best suits your ability to solve your business’s most critical problems.

Consider using industry-standard frameworks to approach the various parts of your SSDLC journey. A framework can guide you through the process and create a structure for delivery, breaking down a significant problem into smaller and more consumable chunks. It can also support the conversation with management and C-level executives on the overall plan and direction of your efforts.

NIST maintains SP 800-218 or the Secure Software Development Framework (SSDF), which is aimed at providing a thorough breakdown of the various secure software development phases and associated levels of maturity in OWASP SAMM, OWASP ASVS, SCFPSSD, etc. Other standards include ISO/IEC 27034 - Application Security, which provides comprehensive guidance on integrating information security controls across all systems development life cycle stages, covering internally developed, acquired, and outsourced software.

We’ve included a list of standards that you may wish to explore below:

• Microsoft Security Development Lifecycle (SDL): Microsoft's methodology for incorporating security and privacy into each phase of the development process.

• Building Security In Maturity Model (BSIMM): A study of real-world software security initiatives that can be used as a model for organizations.

• SAFECode Practices for Secure Software Development (SCFPSSD): Guidance from the Software Assurance Forum for Excellence in Code on secure software development.

The SDLC has various stages in which you can introduce security controls to improve the delivery of your product.

In the design stage, engineers determine the feasibility of meeting the feature requirements. It’s where tooling decisions, delivery mechanisms, and third-party dependencies are identified, discussed, and selected.

From a security perspective, this is where processes such as secure design reviews and threat modeling come into effect. Design reviews and architecture documents provide much-needed context on how a solution will be developed, including future versions; this enables security engineers, architects, and analysts to identify trust boundaries, data stores, and third-party dependencies (in-house, COTS, or open-source)and how the relate to existing design patterns. The idenficiation of new patterns, highlights areas of concern for security teams to delve into, as these new patterns may introduce novel system risks. This early security involvement, saves valuable time and resources in developing solutions that may require extensive configuration or modifications as part of audits and security assessments.

Once the design has been approved, the SDLC shifts into the build or development phase. This is where code is written to implement the approved design.

For a secure SDLC, secure and preventative coding techniques must be used to limit the creation of security issues, which require using tools and processes to identify vulnerabilities and high-risk application patterns. Secure coding techniques include:

• Using automated solutions, such as SAST and SCA, identify potential vulnerabilities

• Leveraging current security guidelines aligned to your application’s programming language and framework

• Secure secrets management

• Don’t Repeat Yourself (DRY) authorization patterns

SAST, DAST, and software composition analysis (SCA) scans are vital to implementing a scalable SSDLC. Unfortunately, automation cannot prevent the creation of all vulnerability types. For example, business logic issues require significant context about the application's behavior to identify a true positive finding, which automated scanners don't have. In these scenarios, it can be helpful to implement security controls before the build and test stages, such as the four-eyes rule, which requires two individuals to review and approve every change. A review should include a security engineer for security-sensitive functionality, as they have the appropriate context for modifying the security control.

Ensuring the enforcement of security testing across your products is essential to providing customers with confidence in their integrity and security.

As with other security controls, an in-depth and multifaceted approach is the most effective way to achieve adequate assurance. Testing should include automated and manual tests across various timeframes focused on different objectives. For example, a feature might get tested by developers and automated scanners during development and testing phases, DAST and in-house penetration testers in non-production, and through an independent third party bi-annually. By including multiple assessments across various development timeframes, you can eliminate bias and information asymmetries through different approaches, which can provide better results and improve coverage.

An application’s lifecycle continues past deployment in production. Therefore, we must also ensure that our security controls are enforced at runtime. This includes the application and the infrastructure used to build, test, and deploy it. From a supply chain security perspective, an attacker compromising the build server could be just as impactful as compromising the application itself. Other examples include runtime security controls, such as RASP for mobile applications or runtime protection for backend processes. These solutions all leverage the application's initial state, or integrity, to determine a baseline. They then use heuristics to recognize potential bad actor behaviour, such as C2 beacons, reverse shells or the spawning of additional processes, and proceed to trigger alerts for security operations teams to investigate.

Effectively securing your software development lifecycle can be challenging, we’ve included a few best practices that you can use to ensure that you maintain course on this journey. Developing an SSDLC is not only about technology or tooling, but also about effective risk management, people management, company culture and feature delivery.

Your engineers are the primary source of value for your product. They’re responsible for the effectiveness of its features, performance, and, in the context of this article, its security. Security tooling deployed within your lifecycle is focused on identifying vulnerabilities that your developers have introduced and aims to limit their deployment to production. Although this is effective, it’s looking to solve the symptom, rather than the underlying root cause. This root cause could be unrealistic deadlines that lead to careless development, requirements that don’t focus on security or a knowledge gap on the security risks that certain features may carry. As a result, developers will introduce more vulnerabilities that slow down development through the remediation process, which kicks in by trying to go to production. Vulnerability remediation becomes more expensive the later in the SDLC they’re discovered. As a result, the cheapest and most effective way of remediating vulnerabilities is by educating your developers so that they have an underlying understanding of security best practices, architecture, and the threats they’re subjected to.

Before a feature can be built, sales, product, and engineering teams define its requirements. Detailed requirements support security teams in identifying and implementing appropriate security controls during the early delivery stages. Feature requirements are often used during security assessments to focus efforts, which ensure the effective use of penetration testing and red team resources. Where business context plays a vital role, such as authorization and privilege escalation issues, precise requirements can ensure that roles and privileges are assigned correctly, and assessments can be used to verify this.

It’s essential to consider your entire attack surface. Modern software is not entirely built in-house but uses a combination of third-party dependencies, deployed using code on trusted cloud providers using a myriad of build and deployment mechanisms. As a result, your attack surface starts from the people in your organization to the endpoints they use and proceeds to the code they write and the 3rd party dependencies they leverage. Therefore, implementing security controls across the entire SDLC and its dependencies is vital to protecting you from insider threats, supply chain attacks, external threat actors, and vendor compromises.

Resources will only be effectively utilized through a thorough understanding of your risk posture. Before tackling the challenge of implementing an SSDLC, it’s important to acquire appropriate data on your current attack surface, highlighting where the greatest issues lie, and where the highest value can be captured. A key component of this process is the prioritization of identified risks. Prioritization should consider risk severity and the cost of implementing and maintaining mitigative or preventative controls compared to risk materialization.

BlackheathPoint excels at providing security assessments across your SDLC to identify your biggest risks. This is accomplished through architecture reviews using processes such as threat modeling and secure design reviews, automated and manual application security assessments, social engineering, and penetration testing. Furthermore, we can support you in implementing risk mitigation security controls to improve your security posture using software engineering best practices that enable scale and improve feature delivery.

Fundamentally, an effective SSDLC minimizes risk and reduces the total number of system vulnerabilities over time. Early issue resolution reduces the total cost of ownership for applications, as addressing problems in later development stages can increase costs up to 100 times. Therefore, for a scalable security function, developers must be in an environment where vulnerability introduction is naturally less likely. As we've indicated previously in the article, a secure SDLC focuses on pulling security earlier into the development process, as it's cheaper and more effective in the early stages. This empowers developers to lead security efforts, not just respond to them, enabling product and application security ownership and significantly enhancing application security and quality.

In the past, implementing an SSDLC was a resource-intensive activity, primarily due to the manual processes involved, which not only required an increase in headcount but also slowed down delivery due to the time needed to complete the assessments/reviews. Modern delivery pipelines are heavily automated, which enables faster and more frequent release cycles. A benefit of this is that it makes the development of a scalable and secure SDLC more accessible to smaller organizations, or teams on smaller budgets. By leveraging automated scanners for vulnerability identification and auto-remediation, gen-AI for threat modeling, and vulnerability and compliance assessments to identify poor coding practices and non-compliance, organizations can look to include preventative security controls in their software delivery process without the challenges with hiring or extensive budget allocations.

We've covered several large topics in this article, from risk management and vulnerability management to secure design. Most importantly, we've discussed how all these topics fit into a Secure Software Development Lifecycle. To achieve this, we've described what an SSDLC is, why you need one, how you can go about implementing it at scale, the challenges you may face, and the benefits you will accrue. An SSDLC is not solely about using application security tools and processes to support software delivery, but it's about the complete lifecycle, from requirements gathering, through development and finally maintenance. As a result, you will leverage different processes, people and tools that will interact with different parts of your business. A reliable and effective SSDLC interacts with teams across the business, including sales, product and SRE. Your security team should leverage both soft and hard skills to build relationships and rapport, alongside the development of reliable and resilient security solutions for your engineers. Lastly, we've mentioned how BlackheathPoint can support you in the development of your SSDLC, starting with risk identification and prioritization through to control selection, implementation, and verification, alongside developer training and awareness.