Software Supply Chain Security

Chapter 4. Secure Development Lifecycle

Secure software is software that has been designed and developed in a way that will continue to function normally even when subjected to malicious attacks. A secure development lifecycle (SDL, although your organization may use another name) consists of activities that strengthen an application or product’s security posture during the software development lifecycle (SDLC). This can also be known as a secure software development lifecycle (S-SDLC) or a Secure Software Development Framework (SSDF).

There are three primary reasons to use an SDL as early and often as possible: to reduce vulnerabilities, reduce the impact of vulnerabilities, and address the original causes of vulnerabilities. As with any software defect, it’s always cheaper and more effective to identify these issues early, and “early” goes all the way back to the initial creation and design of the software. An SDL can provide customers with assurance that a formal process has been followed and can also prevent organizations from repeating the same security mistakes with each release.

As we saw in previous chapters, software supply chain security requires secure development as one of the foundational elements and is now a required element in many cybersecurity legal agreements and certifications. Your organization may already have SDL processes within its existing SDLC or DevOps processes, even if they aren’t called as such. This chapter will discuss the details of secure development lifecycles, augmenting SDLCs, and the more popular SDLs you can use in your organization. For a more detailed discussion of secure development, I recommend the book Alice and Bob Learn Application Security by Tanya Janca.¹

The decision of which SDL to use is usually up to your organization and almost always requires the secure development lifecycle to be adapted to your processes. Once your organization has selected an SDL, document the decision and appropriate details in a corporate SDL policy.

Secure Development Lifecycle Control 01

Control SDL-01: Maintain a secure development lifecycle (SDL) framework and policy that requires employees, contractors, and third parties to follow SDL practices for applications and products.

Key Elements of an SDL

An SDL is the foundation for a secure software supply chain. There are five key elements of an SDL that exist across the various frameworks: security requirements, secure design, secure development, security testing, and vulnerability management. Although you can reduce risk by implementing key elements—such as secure testing—without an SDL, you may still find yourself at a disadvantage since the development team cannot be certain that it has tested what truly needs testing. An SDL’s prescriptive process and controls will enable you to implement a secure software supply chain with secure requirements, design, and development in a reproducible process.

Security Requirements

Security requirements may be defined by laws, regulations, SDL frameworks, and standards, or identified by customers, marketing, internal guidelines, known vulnerabilities, and threat analysis. It is not unusual to have hundreds of security requirements of varying complexity as part of a product, application, or system. For example, marketing requirements for data security can be high-level, such as “personal data shall only be seen by the user,” and then decomposed into dozens of more-detailed, lower-level security requirements, such as “data in transit must be encrypted” and “user access must be authenticated.”

Sometimes there are specific regulations associated with the marketing or technical requirements. For example, there could be cryptography requirements at the marketing level, but regulations may require NIST FIPS 140 for cryptographic modules.² SDL frameworks can also introduce requirements such as the file integrity requirement in ISA/IEC 62443, which ensures users have a way to verify that software has not been altered. Before building applications, you should identify any standards that may apply or certifications you want to pursue, such as the CREST OVS (OWASP Verification Standard) for web and mobile application security standards.³

Product, application, system, and infrastructure security requirements coming from internal technical guidelines, known vulnerabilities, and threat analysis must be continuously updated to address new threats and attack paths. The typical approach for threat analysis comes in the form of threat modeling—a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified and enumerated and countermeasures prioritized.

Another threat analysis approach is to use knowledge bases of curated adversary techniques from real-world observations, such as the MITRE ATT&CK® framework with attack techniques for enterprise systems, mobile applications, and industrial control systems (ICS).⁴ MITRE techniques may include procedure examples, mitigations, detection information, and subtechniques.

The Cyber Kill Chain® framework, developed by Lockheed Martin, is another framework for the identification and prevention of cyber intrusions. The seven-phase attack framework shows the adversary’s actions alongside the defender’s actions to prevent the intrusion.⁵

Similar to the MITRE frameworks, the Open Software Supply Chain Attack Reference (OSC&R) specifically addresses the techniques used to attack software supply chains. In addition to using the information and controls within this book, I recommend you carefully review the OSC&R framework to identify requirements for your organization, products, and applications.⁶

For some software supply chain security risks, you can transform the security control into a security requirement. One such example would be the Infrastructure Security Control IS-08 for patching, as seen in Chapter 3. An  application security requirement or user story specifically to “auto-update software” would resolve part of the IS-08 security control.

At some point, all of these security requirements should be documented in a requirements or user stories database—including the requirements that map to the SDL controls and governance process. Traceability between these requirements, the threat models, and secure test cases are important for validating the requirements prior to a software release and satisfying proof of controls for auditors. At least annually you should review the existing security requirements for enhancements or additions following any changes or improvements to the SDL process and controls as well as new requirements and threats that may have surfaced.

Secure Development Lifecycle Control 02

Control SDL-02: Document and maintain security requirements for applications and products. Include security requirements that are required by processes, controls, applicable laws, and regulations.

Secure Design

The concept of secure design (or secure-by-design) is not only about architecture and infrastructure but also about the security requirements implemented into the system. Within a product or application, secure design is when the team has gone through activities to evaluate the requirements and potential threats to limit risk. Risk to software supply chain security is greatly reduced when secure design activities such as threat modeling are performed. Even products that have been previously designed will benefit greatly from a complete threat model that analyzes entry points, code, services, protocols, APIs, and more.

Threat modeling must be a team sport, or as the Threat Model Manifesto states, there should not be a single hero threat modeler, but multiple people providing representations and views to illuminate different problems.⁷ Threat models should be considered living artifacts that the team must reexamine when architecture, technology, or threats change. This demonstrates that threat models should be updated frequently since the threat landscape is shifting rapidly. Each time risks are identified through threat models, additional security requirements must be added to the product or application.

Additional techniques for securing the product, application, or system design include:

• Analyzing and selecting technologies, components, programming languages, and infrastructure with reduced risk compared to other choices

• Utilizing modular code for easier code updates or reuse

• Isolating critical components and security components from other components during execution

• Providing features for secure deployment, operation, and maintenance

Another type of secure design is “privacy by design” (sometimes called PbD). This includes data security, data protection, and data localization requirements for personal or business data. Considering PbD early in the design process can significantly reduce rearchitecting databases, structures, and common methods such as encryption to meet changing privacy requirements.

Secure Development Lifecycle Control 03

Control SDL-03: Use secure-by-design and privacy-by-design concepts when designing applications and products. Conduct threat modeling on all code, services, systems, infrastructure, APIs, and protocols.

Secure Development

Secure development, another key element in an SDL, involves the methods, techniques, and practices developers should follow and use during code development. This includes important areas such as proper error handling, fault handling, memory management, and secure coding standards. Secure coding standards should always prevent back doors, debug interfaces, error information, or intellectual property from being released. Secure coding rules must be specific for the technology and languages your organization uses, but if your organization does not have secure coding standards in place, refer to “Code Quality” for a list of various standards.

There are many tools available that review code for secure coding risks. Code quality and software composition analysis (SCA) tools are designed to locate faults in free and open source software (FOSS or OSS) by examining code for known vulnerabilities. These tools can also identify license information for potential compliance risks. Some tools even look for hardcoded credentials or compliance to secure coding rules. For more information on open source or code analysis, refer to Chapter 5.

When selecting tools, check for compatibility with applications, operating systems, or platforms. Although OWASP (Open Worldwide Application Security Project) materials were originally designed for web applications, they have expanded to cover more than web technologies. OWASP is known in software development for its “OWASP Top 10” project, which outlines the 10 most critical security concerns for web application security and is revised approximately every three to four years.⁸ The 2017 OWASP list had quite a number of frontend security risks, but the updated 2021 list also highlights risks due to poor SDL practices such as software integrity failures, insecure design, and vulnerable and outdated components.

Secure Development Lifecycle Control 04

Control SDL-04: Follow secure coding rules, leverage tools, and mitigate known weaknesses to develop secure products and applications.

Security Testing

Security testing is the fourth key element in an SDL. Like threat modeling, it’s never too late to start a security testing practice. As shown in Figure 4-1, there are multiple ways to perform security testing, including static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), runtime application security protection (RASP), and penetration testing.⁹ Fuzz testing, which is an automated software testing method that injects malformed, invalid, or unexpected inputs in order to reveal software defects and vulnerabilities, is an effective form of security testing. Additional types of testing include cloud container and deployment testing, as discussed in Chapter 6. The various testing methods should be used in combination with each other and will vary depending on the product, application, system, or infrastructure. 

Figure 4-1. Application security tools and techniques

These tools are only effective at reducing security risk when mitigations (reducing the impact) or remediations (removing the threat) are performed on the findings. Also, these tools may locate hundreds or thousands of vulnerabilities, and most are ineffective in determining if the vulnerability can be exploited. Prioritization, tracking, and V&V (verification and validation) security testing should be used in conjunction with testing tools.

Secure Development Lifecycle Control 05

Control SDL-05: Execute security testing using various tools and techniques on applications and products.

Vulnerability Management

Although vulnerability management activities are contained within the primary SDL practices, this subprocess is critical for identifying, evaluating, and remediating security weaknesses. Throughout the development lifecycle, there are many activities that can identify vulnerabilities, such as during threat modeling, development, code analysis, scanning, and testing. This continuous process is vital for securing products and applications until they reach the end of their lifecycle. To demonstrate your organization’s maturity, you can even choose to certify your vulnerability handling process to the ISO/IEC 30111:2019 standard.¹⁰

In a perfect world, all vulnerabilities would be fixed before releasing the product or application. Unfortunately, we do not live in a perfect world, and thus every release has vulnerabilities that may or may not be exploitable. In 2021, an exploitable vulnerability in Kaseya’s remote monitoring tool gave malicious actors the opportunity to distribute malware to over 1,000 customers before Kaseya could take the software offline.¹¹

When a vulnerability is found, it is usually rated with a scoring system, such as the Common Vulnerability Scoring System (CVSS) standard designed by the Forum of Incident Response and Security Teams (FIRST).¹² However, CVSS is not perfect, and therefore several other scoring and ranking systems now exist to help prioritize vulnerabilities. 

The CVSS standard assigns severity scores to vulnerabilities on a scale of 0 to 10, with 10 being the most severe. The current version of CVSS is a calculated score, generally referenced in vulnerability catalogs, consisting of many metrics, including the attack complexity and what privileges are required. There are three other scoring and ranking systems in use: the Stakeholder-Specific Vulnerability Categorization (SSVC) model, the Exploit Prediction Scoring System (EPSS) model, and the Known Exploited Vulnerability (KEV) catalog.

The SSVC model, designed by Carnegie Mellon University’s Software Engineering Institute and the US Cybersecurity & Infrastructure Agency (CISA), is a decision tree used to prioritize vulnerabilities based on five values, including exploitation status and technical impact.¹³ In the same time period, EPSS was designed by FIRST to estimate the likelihood that a vulnerability will be exploited in the wild.¹⁴ For ease of use, however, the searchable or machine-readable CISA KEV catalog is continuously updated with vulnerabilities that are currently being exploited.¹⁵

Ultimately when prioritizing vulnerabilities, I encourage you to begin with remediating KEVs first, and then the critical and high CVSS vulnerabilities. Remediation can take many forms, such as compensating controls, patching, updating, or replacing the source code. Ideally, all third-party libraries are kept up to date with the latest security patches applied in the source code, but there are situations where the only option is to implement compensating controls in order to prevent exploitation.

In the situation where a third party has reported a vulnerability, you should follow your organization’s vulnerability handling process, and then disclose the mitigations or remediations taken according to your organization’s disclosure policies, as discussed in “Vulnerability Disclosures”.

Secure Development Lifecycle Control 06

Control SDL-06: Maintain a vulnerability management framework, vulnerability handling policy, and vulnerability disclosure policy for identifying, evaluating, remediating, and disclosing vulnerabilities to external parties.

Augmenting an SDLC with SDL

Depending on your organization, you may already have a software development lifecycle (SDLC) with an SDL integrated into it. For those that do have an SDLC without security considerations, you should adjust existing SDLC processes, gates, reviews, templates, checklists, and training to integrate the key SDL elements. By doing so, the SDL will be less of a “checklist” and more of a natural task in the overall development process. Ultimately you want your SDL to be fully integrated and part of the natural day-to-day mindset of your teams, including management, as you develop your applications and products.

The following sections will describe the more popular SDL standards and frameworks. The market to which you sell your application or product can also dictate which SDL would be better received by your customers. If you have not already adopted an SDL, I recommend augmenting your SDLC with ISA/IEC 62443-4-1 (the most comprehensive) or NIST SSDF (rapidly gaining acceptance and free).

ISA/IEC 62443-4-1 Secure Development Lifecycle

The International Society of Automation (ISA), the International Electrotechnical Commission (IEC), and the International Organization for Standardization (ISO) collaborated to create and release the “62443-4-1:2018 Secure product development lifecycle requirements” (hereafter referred to as “4-1 SDL”), which are available for purchase on the ISA and IEC web stores.¹⁶ The 4-1 SDL standard specifies secure development process requirements for industrial automation and control systems products.  These process requirements can be applied to new or existing software or firmware products.

The 4-1 SDL standard is the most robust SDL available for developing software and firmware. The technical committee that created the standard had taken many inputs from the available SDLs, security frameworks, security standards, and industry experience securing critical systems. The 4-1 SDL standard is one part of the overall ISA/IEC 62443 series, which provides standards for components, systems, integrations, deployments, and operations.¹⁷ The 4-1 SDL standard is a baseline requirement for products and systems to receive additional ISA/IEC 62443 certifications, but as an SDL, it is broadly applicable for any product or application, not just for those in industrial systems.

The following list notes the eight practices within ISA/IEC 62443-4-1 SDL, as shown in Figure 4-2:

• Security management

• Specification of security requirements

• Secure by design

• Secure implementation (development)

• Security verification and validation testing

• Management of security-related issues (vulnerabilities)

• Security update documentation

• Security guidelines

Figure 4-2. Eight practices of ISA/IEC 62443-4-1

The MDCG 2019-16 (Medical Device Coordination Group Document—Guidance on Cybersecurity for medical devices) document also uses these same eight practices.¹⁸ Organizations that   develop products for industrial control systems (ICS), which are used in manufacturing, energy systems, water treatment, and more, often use 4-1 SDL as the foundation for their corporate SDLs and certify their global SDL frameworks through independent third-party certifiers. 4-1 SDL is a strong, solid framework for software and firmware, but needs some updates to reflect requirements for cloud-hosted applications and small Agile teams.

NIST SSDF

The United States National Institute of Standards and Technology (NIST) produces many supply chain security documents and standards, one of which is NIST Special Publication 800–218. The NIST SP 800-218 document is  better known as the “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities,” or shortened as SSDF.¹⁹ The February 2022 document, current at the time of writing, includes an impressive cross-reference to the various secure software development frameworks. You can leverage this document for augmenting or establishing secure SDLC practices for your software suppliers.

The SSDF is organized into four main practice areas:

• PO: Prepare the Organization

• PS: Protect Software

• PW: Produce Well-Secured Software

• RV: Respond to Vulnerabilities

SSDF is a good foundation for an SDL, but it is not comprehensive enough to establish a secure software supply chain even when incorporating the NIST CSF (as described in Chapter 2). To evaluate and identify the risks in the entire software supply chain, you will need multiple frameworks or the core set of controls as identified throughout this book.

The SSDF does not provide specific guidance on implementing each SDL practice or control. However, there is an excellent supplemental spreadsheet provided with the SSDF document. The supplemental spreadsheet contains notional implementation examples, which can be useful to provide explanations and potential use cases. If you have already implemented other framework controls such as ISA/IEC 62443 or NIST SP 800–53, you will find the cross-reference available in the supplemental spreadsheet to be very helpful.

Microsoft SDL

Microsoft  first introduced its SDL (which Microsoft refers to as a Security Development Lifecycle) in 2008 and has been a solid supporter of SDL practices in all the standards and frameworks mentioned in this chapter.²⁰ Microsoft provides a free document titled “Simplified Implementation of the Microsoft SDL” for download on its website along with a Simplified SDL spreadsheet.²¹ Prior to the release of NIST SSDF, the Microsoft SDL documentation was my recommended guidance to nonindustrial control system companies, especially small organizations or startups. Although Figure 4-3 implies a waterfall process, Microsoft SDL is adaptable to Agile processes as well.

Figure 4-3. The Microsoft Security Development Lifecycle—simplified

Microsoft has supplemented its SDL with other topics on its Security Engineering portal.²² The most important enhancement is the Secure DevOps practices, as mentioned in Chapter 6, which can be considered as the basis for a Cloud SDL.²³

ISO/IEC 27034 Application Security

The International Organization of Standardization (ISO) and the International Electrotechnical Commission (IEC) collaborated to create and release ISO/IEC 27034 as part of the overall ISO 27k series. The ISO/IEC 27034-1:2011 standard “Information Technology—Security Techniques—Application Security” offers guidance for organizations acquiring, developing, or managing applications.²⁴ The ISO 27034 series also provides guidance to implement and demonstrate application security governance as well as application security management by helping to define, implement, and maintain a level of trust related to each application’s lifecycle.

The 27034 standard works well for software applications in organizations that have adopted the ISO 27k standards and for those that are just starting to implement security for their applications. It is closely aligned to the ISO 27005 information security risk management standard. There are five main elements to the 27034 standard:

Application Security Controls (ASCs)

Verifiable controls linked to the organization’s security requirements, classified by level of trust, to prevent weaknesses in and around applications, as shown in Figure 4-4.

Organization Normative Framework (ONF)

A repository of ASCs and processes used to normalize application security best practices across the organization.

ONF Management Process

Manages an organization’s priorities and defines ASCs in addition to other processes and security activities for the organization’s applications.

Application Security Management Process (ASMP)

Assesses risks, defines requirements, and tests ASCs using verification measurements.

Application Normative Framework (ANF)

Collects and stores ASCs for a particular application as a subset to ONF, as well as process outcomes as security evidence for that application.

Figure 4-4. ISO/IEC 27034 Application Security Control

At first glance, many organizations consider the ISO 27034 standard to be complex, abstract, and of limited use to software manufacturers. However, while the mapping to specific situations may seem overwhelming to most businesses, the 27034 standard offers a step-by-step approach that allows companies to integrate application security into their existing processes according to their level of maturity, their priorities, and the resources they have available. This approach allows individuals, small organizations, and agile organizations to develop the ASCs for their applications in their context, and then continue to integrate the elements proposed by the 27034 standard as and when their security needs arise. For organizations already certified to many ISO 27k standards, the 27034 standard is worth considering.

SAFECode

The Software Assurance Forum for Excellence in Code (SAFECode) is a nonprofit collaboration of companies that first documented SDL practices starting in 2008. Now in its third edition, “Fundamental Practices for Secure Software Development” provides a good foundation for secure development and testing.²⁵ The document references separate publications, including “Practices for Secure Development of Cloud Applications,” which was released in 2013, and guidance for Agile practitioners in “Practical Security Stories and Security Tasks for Agile Development Environments” in 2012.^26,27

All the SAFECode documents are well written and provide details on the core aspects of an SDL. The documents do not, however, provide prescriptive and enumerated requirements (e.g., Secure Design requirement number n). Without a set of controls, a development organization cannot demonstrate to a third party that SDL was followed for every release. I do believe the SAFECode publications can be used to augment a set of controls and provide materials for a solid training program. Although the cloud document is somewhat out of date and does not mention serverless computing, the Agile document contains many user stories, backlog tasks, and vulnerability weaknesses to support secure development and testing.

SDL Considerations for IoT, OT, and Embedded Systems

An SDL is applicable for all products and applications, but there are additional considerations for devices such as IoT, OT (operational technology that can detect or cause a change in physical processes), and embedded systems (combination of computer hardware and software). As mentioned in “Device Protection Measures”, there are different ways to build in protection for devices through additional requirements, design considerations, development, and testing of the software, firmware, and hardware.

For IoT devices, there are new standards, baselines (minimum requirements), and labeling programs being released each year, and many are specific to the type of IoT device. Labeling programs require manufacturers to meet a certain cybersecurity standard before they can place a specific logo (trust mark) on the product. For example, the Singapore IoT Cybersecurity Labelling Scheme was released in 2021 and now includes many categories of consumer IoT devices such as routers, smart home hubs, and smart home devices.²⁸ Finland and Germany have also released cybersecurity labels, and the US IoT Cybersecurity Labeling for Consumers program is in design but was not officially released at the time this book was published.

In regard to OT products and embedded systems, the standards and baselines are very similar to IoT, but OT products generally have a correlation with safety either directly (e.g., controlling wastewater systems or manufacturing machinery) or indirectly (e.g., reading sensors located in a data center). There are a number of standards for IoT/OT, including some country- and industry-specific requirements. I have provided the following list, but you will need to monitor for new requirements since there are more releasing all the time:

• ISA/IEC 62443-4-2: technical security requirements for components²⁹

• ETSI EN 303 645: cybersecurity for consumer IoT³⁰

• ISO/IEC 27400:2022: IoT security and privacy guidelines³¹

• ISO/SAE 21434: automotive cybersecurity standard³²

• UL 2900-1: network-connectable products³³

• CTIA IoT Cybersecurity Certification: IoT baseline for the purpose of certification³⁴

• UK Product Security and Telecommunications Infrastructure Act 2022: internet-connectable products³⁵

• EU Cybersecurity Resilience Act (CRA): draft regulation includes IoT scope³⁶

• US NIST IR 8259 Series: IoT recommendations and baselines³⁷

• US California Law SB-327: first law specifically on IoT security³⁸

• US Oregon Law HB 2395: consumer IoT law³⁹

Product and Application Security Metrics

A frequent question from those new to application security is “What metrics (a number) or measurements (relationship between numbers) do I use to assess an organization or product?” The answer, unfortunately, is not simple because it depends on where you are on your security journey and what is reasonable to capture.

My personal favorite for newer security programs is an SDL adoption measurement that uses compliance metrics from specific processes, such as penetration tests and security reviews. For example, there should be no easy vulnerabilities found in the penetration test, which has a complexity scoring system of easy, moderate, and difficult. You can combine any number of metrics and apply certain weights (e.g., three times the weight for a product that had an easy vulnerability) to define a measurement system that is unique to your organization.

For a list of many application security metrics and measurements, I recommend the “Capability Maturity Model and Security Metrics” chapter in The Purple Book of Software Security.⁴⁰ The Purple Book Community of software security experts, of which I am a founding member, has also designed the Scalable Software Security Maturity Model (S3M2) for organizations to assess their security maturity.⁴¹ This software security model can be used by organizations of any size, even startups, and it is applicable to every industry and technology.

There are three other models available: ISACA/Carnegie Mellon University CMMI, Synopsys BSIMM, and OWASP SAMM. The Capability Maturity Model Integration (CMMI) uses well-known maturity levels to assess the capability of the process being measured. Available for purchase, CMMI is a good choice for organizations that have already adopted other capability maturity models and may not need a dedicated focus on software security.⁴²

The Synopsys BSIMM (Building Security in Maturity Model) is available as an assessment service and thus is mainly used by larger companies. Although it is not a maturity assessment, it does provide assessment and comparison to peer companies and industry. Leveraging the results of the assessments conducted each year, Synopsys then produces a Trends & Insights report with key findings and recommendations.⁴³

The OWASP SAMM (Software Assurance Maturity Model) project was specifically designed for application security and is available free to any organization.⁴⁴ It is a comprehensive application security maturity model, but it does not include other important areas of organization security posture such as network security and physical security. I suggest you review both the OWASP SAMM and the Purple Book S3M2 to find a maturity model that works well for your organization.

Summary

Secure development lifecycles are the cornerstone of a secure software supply chain. With the attention being placed on secure development and secure testing practices, it will soon become common practice to have a corporate SDL policy for the development of internal, enterprise, or customer applications and products. Although there are various frameworks and approaches to SDLs, they all center around the main principles of security requirements, secure design, secure development, and security testing.

By incorporating these key principles into a corporate SDLC, the security posture of applications and products will improve and can respond when vulnerabilities are discovered. In Chapter 5, I’ll discuss the various types of source code and how to secure the build and deployment processes.

¹ Tanya Janca, Alice and Bob Learn Application Security (Wiley, 2020).

² “Security Requirements for Cryptographic Modules”, NIST, March 19, 2019.

³ “CREST OVS Web Application Programme”, CREST, accessed December 10, 2023.

⁴ MITRE ATT&CK®, accessed December 10, 2023.

⁵ Lockheed Martin Corporation, Gaining the Advantage: Applying Cyber Kill Chain Methodology to Network Defense, 2015.

⁶ “A New Open Framework for Releasing Secure Products”, PBOM, accessed December 10, 2023.

⁷ “Threat Modeling Manifesto”, accessed October 26, 2023.

⁸ “OWASP Top 10”, OWASP, accessed November 11, 2023.

⁹ Sherif Koussa, “What Do SAST, DAST, IAST and RASP Mean to Developers?” Software Secured, accessed December 10, 2023.

¹⁰ “ISO/IEC 30111:2019 Vulnerability Handling Processes”, ISO, accessed December 10, 2023.

¹¹ Charlie Osborne, “Updated Kaseya Ransomware Attack FAQ: What We Know Now”, ZDNET, July 23, 2021.

¹² “Common Vulnerability Scoring System SIG”, Forum of Incident Response and Security Teams, accessed December 10, 2023.

¹³ “Stakeholder-Specific Vulnerability Categorization (SSVC)”, US Cybersecurity & Infrastructure Security Agency, accessed December 10, 2023.

¹⁴ “Exploit Prediction Scoring System (EPSS)”, Forum of Incident Response and Security Teams, accessed December 10, 2023.

¹⁵ “Known Exploited Vulnerabilities Catalog”, US Cybersecurity & Infrastructure Security Agency, accessed December 10, 2023.

¹⁶ See “ANSI/ISA-62443-4-1-2018, Security for Industrial Automation and Control Systems—Part 4-1: Secure Product Development Lifecycle Requirements (Formerly Part 4-1: Product Security Development Life-Cycle)”, International Society of Automation, accessed December 10, 2023; and “IEC 62443-4-1:2018”, International Electrotechnical Commission, January 15, 2018, IEC.

¹⁷ International Society of Automation-Global Cybersecurity Alliance, Quick Start Guide: An Overview of ISA/IEC 62443 Standards, June 2020.

¹⁸ Medical Device Coordination Group, MDCG 2019-16—Guidance on Cybersecurity for Medical Devices, July 2020.

¹⁹ Murugiah Souppaya, Karen Scarfone, and Donna Dodson, “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities”, NIST, February 2022.

²⁰ “Microsoft Security Development Lifecycle (SDL)”, Microsoft, accessed December 29, 2022.

²¹ Microsoft Download Center, accessed December 29, 2022.

²² “Security Engineering Portal”, Microsoft, accessed December 29, 2022.

²³ “Security DevOps”, Microsoft, accessed December 29, 2022.

²⁴ “ISO/IEC 27034-1:2011 Information Technology—Security Techniques—Application Security”, ISO, accessed December 10, 2023.

²⁵ SAFECode, Fundamental Practices for Secure Software Development, third edition, March 2018.

²⁶ SAFECode and Cloud Security Alliance, Practices for Secure Development of Cloud Applications, December 5, 2013.

²⁷ SAFECode, Practical Security Stories and Security Tasks for Agile Development Environments, July 17, 2012.

²⁸ “Cybersecurity Labelling Scheme (CLS)”, Cyber Security Agency of Singapore, accessed December 10, 2023.

²⁹ “ANSI/ISA-62443-4-2-2018, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS Components, 2nd Printing”, International Society of Automation, accessed December 10, 2023.

³⁰ ETSI, Cyber Security for Consumer Internet of Things: Baseline Requirements, March 31, 2021.

³¹ “ISO/IEC 27400:2022—Cybersecurity—IoT Security and Privacy—Guidelines”, ISO, accessed December 10, 2023.

³² “ISO/SAE 21434:2021 Road Vehicles—Cybersecurity Engineering”, ISO, accessed December 10, 2023.

³³ “UL 2900-1 Ed. 1-2017—Standard for Software Cybersecurity for Network-Connectable Products, Part 1: General Requirements”, ANSI Webstore, accessed December 10, 2023.

³⁴ “Internet of Things (IoT) Cybersecurity Certification”, CTIA Certification, accessed December 10, 2023.

³⁵ “Product Security and Telecommunications Infrastructure Act 2022”, legislation.gov.uk, accessed December 10, 2023.

³⁶ “European Cyber Resilience Act (CRA)”, accessed December 10, 2023.

³⁷ “NISTIR 8259 Series”, NIST, accessed December 10, 2023.

³⁸ “California SB-327 Information Privacy: Connected Devices”, California Legislature, September 28, 2018.

³⁹ A-Engrossed House Bill 2395, Oregon Legislature, accessed December 10, 2023.

⁴⁰ Purple Book Community, “Capability Maturity Model and Security Metrics”, in The Purple Book of Software Security, accessed December 10, 2023.

⁴¹ “Scalable Software Security Maturity Model (S3M2)”, Purple Book Community, accessed December 10, 2023.

⁴² “CMMI Development”, CMMI Institute, accessed December 10, 2023.

⁴³ Synopsys, BSIMM 13: Trends & Insights Report 2022, 2022.

⁴⁴ “OWA Software Assurance Maturity Model”, OWASP, accessed December 10, 2023.