This document discusses implementing a secure software development lifecycle (SDLC). It emphasizes building security into software from the start rather than adding it later. The summary is:
The document outlines a secure SDLC process involving defining security requirements, designing for security, implementing secure coding practices, testing software security, and ongoing security monitoring. It notes that software security is a shared responsibility and discusses challenges like team pushback and measuring security benefits. The document also presents a case study of a company that implemented a secure SDLC process to address client security issues and prevent future problems.
The document outlines a cybersecurity reference architecture that provides:
1. Active threat detection across identity, apps, infrastructure, and devices using tools like Azure Security Center, Windows Defender ATP, and Enterprise Threat Detection.
2. Protection of sensitive data through information protection, classification, and data loss prevention tools.
3. Management of identity and access to securely embrace identity as the primary security perimeter.
These are slides from local security chapters meetup, Here I tried to explain the challenges in appsec and complete framework for different life cycle of secure software development cycle
Cybersecurity roadmap : Global healthcare security architecturePriyanka Aash
Using NIST cybersecurity framework, one of the largest healthcare IT firms in the US developed the global security architecture and roadmap addressing security gaps by architecture domain and common security capability. This session will discuss the architecture framework, capability matrix, the architecture development methodology and key deliverables.
(Source : RSA Conference USA 2017)
This article examines the emerging need for software assurance. As defense contractors continue to develop systems for the Department of Defense (DoD) those systems must meet stringent requirements for deployment. However as over half of the vulnerabilities are found at the application layer organizations must ensure that proper mechanisms are in place to ensure the integrity, availability, and confidentiality of the code is maintained. Download paper at https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_(SDLC)
Identity and Access Management (IAM) is a crucial part of living in a connected world. It involves managing multiple identities of an individual or entity, distributed across disparate portals. In an enterprise, IAM solutions serve as a mean to secure access, control user activities and manage authentication for an App or a group of software (infrastructure).
This detailed PowerPoint brings you the most fundamental concepts and ideas related to identity and access management. Plus, we have debunked some popular IAM myths, so do checkout!
IAM refers to identity and access management. It involves managing user identities and access across various systems and applications. In cloud computing, IAM takes on additional considerations like managing access to cloud-based applications and services. Key aspects of IAM include provisioning and de-provisioning user accounts, authentication, authorization, role-based access controls, and auditing. IAM aims to bring order to complex identity and access environments while also improving security, compliance and user experience.
The document discusses the MITRE ATT&CK framework, which is a knowledge base of adversary behaviors and tactics collected from real-world observations. It describes how the framework categorizes behaviors using tactics, techniques, and procedures. The framework can be used for threat intelligence, detection and analytics, adversary emulation, and assessment and engineering. The document provides examples of how organizations can map their detection capabilities and data sources to techniques in the framework to improve visibility of attacks. It cautions against misusing the framework as a checklist rather than taking a threat-informed approach.
This document discusses implementing a secure software development lifecycle (SDLC). It emphasizes building security into software from the start rather than adding it later. The summary is:
The document outlines a secure SDLC process involving defining security requirements, designing for security, implementing secure coding practices, testing software security, and ongoing security monitoring. It notes that software security is a shared responsibility and discusses challenges like team pushback and measuring security benefits. The document also presents a case study of a company that implemented a secure SDLC process to address client security issues and prevent future problems.
The document outlines a cybersecurity reference architecture that provides:
1. Active threat detection across identity, apps, infrastructure, and devices using tools like Azure Security Center, Windows Defender ATP, and Enterprise Threat Detection.
2. Protection of sensitive data through information protection, classification, and data loss prevention tools.
3. Management of identity and access to securely embrace identity as the primary security perimeter.
These are slides from local security chapters meetup, Here I tried to explain the challenges in appsec and complete framework for different life cycle of secure software development cycle
Cybersecurity roadmap : Global healthcare security architecturePriyanka Aash
Using NIST cybersecurity framework, one of the largest healthcare IT firms in the US developed the global security architecture and roadmap addressing security gaps by architecture domain and common security capability. This session will discuss the architecture framework, capability matrix, the architecture development methodology and key deliverables.
(Source : RSA Conference USA 2017)
This article examines the emerging need for software assurance. As defense contractors continue to develop systems for the Department of Defense (DoD) those systems must meet stringent requirements for deployment. However as over half of the vulnerabilities are found at the application layer organizations must ensure that proper mechanisms are in place to ensure the integrity, availability, and confidentiality of the code is maintained. Download paper at https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_(SDLC)
Identity and Access Management (IAM) is a crucial part of living in a connected world. It involves managing multiple identities of an individual or entity, distributed across disparate portals. In an enterprise, IAM solutions serve as a mean to secure access, control user activities and manage authentication for an App or a group of software (infrastructure).
This detailed PowerPoint brings you the most fundamental concepts and ideas related to identity and access management. Plus, we have debunked some popular IAM myths, so do checkout!
IAM refers to identity and access management. It involves managing user identities and access across various systems and applications. In cloud computing, IAM takes on additional considerations like managing access to cloud-based applications and services. Key aspects of IAM include provisioning and de-provisioning user accounts, authentication, authorization, role-based access controls, and auditing. IAM aims to bring order to complex identity and access environments while also improving security, compliance and user experience.
The document discusses the MITRE ATT&CK framework, which is a knowledge base of adversary behaviors and tactics collected from real-world observations. It describes how the framework categorizes behaviors using tactics, techniques, and procedures. The framework can be used for threat intelligence, detection and analytics, adversary emulation, and assessment and engineering. The document provides examples of how organizations can map their detection capabilities and data sources to techniques in the framework to improve visibility of attacks. It cautions against misusing the framework as a checklist rather than taking a threat-informed approach.
** CyberSecurity Certification Training: https://www.edureka.co/cybersecurity-certification-training **
This Edureka tutorial on "Cybersecurity Frameworks" will help you understand why and how the organizations are using the cybersecurity framework to Identify, Protect and Recover from cyber attacks.
Cybersecurity Training Playlist: https://bit.ly/2NqcTQV
Machine Learning & Cyber Security: Detecting Malicious URLs in the HaystackAlistair Gillespie
This document discusses using machine learning and Python to detect malicious URLs. It presents a threat science framework with stages including know the user, know the threat, data acquisition and understanding, feature engineering, modeling and evaluation, and deployment. For detecting malicious URLs specifically, it describes collecting benign and malicious URL data, exploring and engineering features, using models like random forest and deep neural networks, and evaluating performance with metrics like F1 score and confusion matrices. Parameter tuning and model explainability are also covered. The overall goal is to build an intelligent ecosystem of ML models to provide superior cyber defense against evolving threats.
IBM AppScan - the total software security solution, Content:
- Introduction to security
- Best Practices for Application Security
- IBM AppScan security solution
- DEMO
This document discusses threat modeling for software applications. It covers the key stages of threat modeling including decomposing the application, determining and ranking threats using STRIDE, and determining countermeasures. Specific topics covered include threat modeling approaches, data flow diagrams, trust levels, the STRIDE framework for analyzing spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege threats. It also discusses mobile threat modeling and provides an example threat analysis of a student results portal application.
This document summarizes ABN AMRO's DevSecOps journey and initiatives. It discusses their implementation of continuous integration and delivery pipelines to improve software quality, reduce lead times, and increase developer productivity. It also covers their work to incorporate security practices like open source software management, container security, and credentials management into the development lifecycle through techniques like dependency scanning, security profiling, and a centralized secrets store. The presentation provides status updates on these efforts and outlines next steps to further mature ABN AMRO's DevSecOps capabilities.
This document discusses vulnerability assessment and penetration testing. It defines them as two types of vulnerability testing that search for known vulnerabilities and attempt to exploit vulnerabilities, respectively. Vulnerability assessment uses automated tools to detect known issues, while penetration testing employs hacking techniques to demonstrate how deeply vulnerabilities could be exploited like an actual attacker. Both are important security practices for identifying weaknesses and reducing risks, but require different skills and have different strengths, weaknesses, frequencies, and report outputs. Reasons for vulnerabilities include insecure coding, limited testing, and misconfigurations. The document outlines common vulnerability and attack types as well as how vulnerability assessment and penetration testing are typically conducted.
The document discusses the NIST Cybersecurity Framework, which provides guidelines for critical infrastructure security and management of cybersecurity risks. It was created through a collaboration between government and industry to help organizations manage and reduce cybersecurity risks. The framework consists of five concurrent and continuous functions - Identify, Protect, Detect, Respond, Recover. It also outlines implementation tiers from Partial to Adaptive to help organizations determine their cybersecurity risk management practices. The framework is meant to be flexible and not prescriptive in order to accommodate different sectors and risks profiles.
This document discusses penetration testing and ethical hacking. It provides an overview of penetration testing methodology and the services offered by Endava, including regular vulnerability scans, penetration tests, PCI assessments, security trainings, audits, and intrusion monitoring solutions. The presenter, Maxim Catanoi, is an IT security consultant at Endava with over 9 years of experience and multiple security certifications.
Many serverless applications need a way to manage end user identities and support sign-ups and sign-ins. Join this session to learn real-world design patterns for implementing authentication and authorization for your serverless application—such as how to integrate with social identity providers (such as Google and Facebook) and existing corporate directories. We cover how to use Amazon Cognito identity pools and user pools with API Gateway, Lambda, and IAM.
This document provides an overview of cybersecurity domains including:
- Security architecture, network design, access control, identity management, data protection, cloud security, endpoint security, security operations, threat intelligence, governance, compliance, risk management, application security, physical security, and career development in cybersecurity.
It outlines key areas within each domain such as data leakage prevention, privileged access management, encryption, incident response, vulnerability management, laws and regulations, third-party risk, penetration testing, user education, and frameworks.
The document was created by Henry Jiang in March 2021 as a map of major cybersecurity domains and topics.
Here is your guide on how to progress through the cyber security career ladder. This resource shows you all the different cyber security roles and the qualifications needed for each!
The document presents a security reference architecture with use cases. It includes sections on user/device security, application security, network security, SASE integration, common identity, converged multi-cloud policy, and securing IoT/OT environments. Diagrams show how different security tools and services fit together across networks, users, applications, and clouds to provide a zero trust architecture.
Scaling threat detection and response in AWS - SDD312-R - AWS re:Inforce 2019 Amazon Web Services
The document outlines an AWS security workshop on scaling threat detection and response. It provides an agenda for the workshop consisting of four modules: environment setup, attack simulation, detecting and responding to the attack, and a discussion/review at the end. It provides guidance on using the AWS event engine for the workshop and directions for completing each module, including building detective controls in Module 1, simulating an attack in Module 2, and detecting and responding to the attack in Module 3.
The document discusses aligning to the NIST Cybersecurity Framework (CSF) in the AWS cloud. It provides an overview of the NIST CSF and why organizations use it. The document then details how AWS services align with the CSF based on third-party assessments. It provides a mapping of AWS services to the CSF functions of Identify, Protect, Detect, Respond, and Recover along with associated customer and AWS responsibilities. The mapping is intended to help customers leverage AWS solutions to facilitate their own alignment with the NIST CSF.
Risk management is the process of analyzing exposure to risk and determining how to best handle such exposure.
Issues important to top management typically receive lot of attention from many quarters. Since top management cares about risk management, a number of popular IT risk-management frameworks have emerged.
SECURING SOFTWARE DEVELOPMENT STAGES USING ASPECT-ORIENTATION CONCEPTSijseajournal
The document summarizes research on securing software development stages using aspect-orientation concepts. It proposes a model called the Aspect-Oriented Software Security Development Life Cycle (AOSSDLC) which incorporates security activities into each stage of the software development life cycle. The model aims to efficiently integrate security as a cross-cutting concern using aspect orientation. It is concluded that aspect orientation allows security features to be installed without changing the existing software structure, providing benefits over other approaches.
This document provides a checklist of secure coding practices for software developers. It covers topics such as input validation, output encoding, authentication, session management, access control, cryptography, error handling, data protection, and general coding practices. Implementing the practices in this checklist can help mitigate common software vulnerabilities and security issues. The document recommends defining security roles and responsibilities, providing training, and following a secure software development lifecycle model.
** CyberSecurity Certification Training: https://www.edureka.co/cybersecurity-certification-training **
This Edureka tutorial on "Cybersecurity Frameworks" will help you understand why and how the organizations are using the cybersecurity framework to Identify, Protect and Recover from cyber attacks.
Cybersecurity Training Playlist: https://bit.ly/2NqcTQV
Machine Learning & Cyber Security: Detecting Malicious URLs in the HaystackAlistair Gillespie
This document discusses using machine learning and Python to detect malicious URLs. It presents a threat science framework with stages including know the user, know the threat, data acquisition and understanding, feature engineering, modeling and evaluation, and deployment. For detecting malicious URLs specifically, it describes collecting benign and malicious URL data, exploring and engineering features, using models like random forest and deep neural networks, and evaluating performance with metrics like F1 score and confusion matrices. Parameter tuning and model explainability are also covered. The overall goal is to build an intelligent ecosystem of ML models to provide superior cyber defense against evolving threats.
IBM AppScan - the total software security solution, Content:
- Introduction to security
- Best Practices for Application Security
- IBM AppScan security solution
- DEMO
This document discusses threat modeling for software applications. It covers the key stages of threat modeling including decomposing the application, determining and ranking threats using STRIDE, and determining countermeasures. Specific topics covered include threat modeling approaches, data flow diagrams, trust levels, the STRIDE framework for analyzing spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege threats. It also discusses mobile threat modeling and provides an example threat analysis of a student results portal application.
This document summarizes ABN AMRO's DevSecOps journey and initiatives. It discusses their implementation of continuous integration and delivery pipelines to improve software quality, reduce lead times, and increase developer productivity. It also covers their work to incorporate security practices like open source software management, container security, and credentials management into the development lifecycle through techniques like dependency scanning, security profiling, and a centralized secrets store. The presentation provides status updates on these efforts and outlines next steps to further mature ABN AMRO's DevSecOps capabilities.
This document discusses vulnerability assessment and penetration testing. It defines them as two types of vulnerability testing that search for known vulnerabilities and attempt to exploit vulnerabilities, respectively. Vulnerability assessment uses automated tools to detect known issues, while penetration testing employs hacking techniques to demonstrate how deeply vulnerabilities could be exploited like an actual attacker. Both are important security practices for identifying weaknesses and reducing risks, but require different skills and have different strengths, weaknesses, frequencies, and report outputs. Reasons for vulnerabilities include insecure coding, limited testing, and misconfigurations. The document outlines common vulnerability and attack types as well as how vulnerability assessment and penetration testing are typically conducted.
The document discusses the NIST Cybersecurity Framework, which provides guidelines for critical infrastructure security and management of cybersecurity risks. It was created through a collaboration between government and industry to help organizations manage and reduce cybersecurity risks. The framework consists of five concurrent and continuous functions - Identify, Protect, Detect, Respond, Recover. It also outlines implementation tiers from Partial to Adaptive to help organizations determine their cybersecurity risk management practices. The framework is meant to be flexible and not prescriptive in order to accommodate different sectors and risks profiles.
This document discusses penetration testing and ethical hacking. It provides an overview of penetration testing methodology and the services offered by Endava, including regular vulnerability scans, penetration tests, PCI assessments, security trainings, audits, and intrusion monitoring solutions. The presenter, Maxim Catanoi, is an IT security consultant at Endava with over 9 years of experience and multiple security certifications.
Many serverless applications need a way to manage end user identities and support sign-ups and sign-ins. Join this session to learn real-world design patterns for implementing authentication and authorization for your serverless application—such as how to integrate with social identity providers (such as Google and Facebook) and existing corporate directories. We cover how to use Amazon Cognito identity pools and user pools with API Gateway, Lambda, and IAM.
This document provides an overview of cybersecurity domains including:
- Security architecture, network design, access control, identity management, data protection, cloud security, endpoint security, security operations, threat intelligence, governance, compliance, risk management, application security, physical security, and career development in cybersecurity.
It outlines key areas within each domain such as data leakage prevention, privileged access management, encryption, incident response, vulnerability management, laws and regulations, third-party risk, penetration testing, user education, and frameworks.
The document was created by Henry Jiang in March 2021 as a map of major cybersecurity domains and topics.
Here is your guide on how to progress through the cyber security career ladder. This resource shows you all the different cyber security roles and the qualifications needed for each!
The document presents a security reference architecture with use cases. It includes sections on user/device security, application security, network security, SASE integration, common identity, converged multi-cloud policy, and securing IoT/OT environments. Diagrams show how different security tools and services fit together across networks, users, applications, and clouds to provide a zero trust architecture.
Scaling threat detection and response in AWS - SDD312-R - AWS re:Inforce 2019 Amazon Web Services
The document outlines an AWS security workshop on scaling threat detection and response. It provides an agenda for the workshop consisting of four modules: environment setup, attack simulation, detecting and responding to the attack, and a discussion/review at the end. It provides guidance on using the AWS event engine for the workshop and directions for completing each module, including building detective controls in Module 1, simulating an attack in Module 2, and detecting and responding to the attack in Module 3.
The document discusses aligning to the NIST Cybersecurity Framework (CSF) in the AWS cloud. It provides an overview of the NIST CSF and why organizations use it. The document then details how AWS services align with the CSF based on third-party assessments. It provides a mapping of AWS services to the CSF functions of Identify, Protect, Detect, Respond, and Recover along with associated customer and AWS responsibilities. The mapping is intended to help customers leverage AWS solutions to facilitate their own alignment with the NIST CSF.
Risk management is the process of analyzing exposure to risk and determining how to best handle such exposure.
Issues important to top management typically receive lot of attention from many quarters. Since top management cares about risk management, a number of popular IT risk-management frameworks have emerged.
SECURING SOFTWARE DEVELOPMENT STAGES USING ASPECT-ORIENTATION CONCEPTSijseajournal
The document summarizes research on securing software development stages using aspect-orientation concepts. It proposes a model called the Aspect-Oriented Software Security Development Life Cycle (AOSSDLC) which incorporates security activities into each stage of the software development life cycle. The model aims to efficiently integrate security as a cross-cutting concern using aspect orientation. It is concluded that aspect orientation allows security features to be installed without changing the existing software structure, providing benefits over other approaches.
This document provides a checklist of secure coding practices for software developers. It covers topics such as input validation, output encoding, authentication, session management, access control, cryptography, error handling, data protection, and general coding practices. Implementing the practices in this checklist can help mitigate common software vulnerabilities and security issues. The document recommends defining security roles and responsibilities, providing training, and following a secure software development lifecycle model.
Want to learn about the latest NIST Cybersecurity Framework (CSF) 2.0?
We've just uploaded a recording of our 2-hour training workshop organized by the ISC2 El Djazair Chapter and delivered by cybersecurity instructor Bachir Benyammi.
In this workshop, you'll gain insights on:
- NIST CSF 2.0 components (Core, Tiers, and Profiles)
- Implementing the framework for your specific needs
- Improving your organization's cybersecurity posture
- Assessing your cybersecurity maturity
- Examples of assessment tools
Watch the full workshop on our YouTube channel: https://lnkd.in/dXEbp8QM
OWASP Secure Coding Practices - Quick Reference GuideLudovic Petit
This document provides a quick reference guide for secure coding practices. It contains a checklist of over 50 secure coding practices organized into categories such as input validation, authentication, session management, and access control. The introduction provides an overview of why secure coding is important and recommends establishing secure development processes and training developers. It defines key security concepts like threats, vulnerabilities, and risks. The goal is to help development teams integrate security practices into the software development lifecycle to mitigate common vulnerabilities.
The Databricks AI Security Framework (DASF), oh what a treasure trove of wisdom it is, bestows upon us the grand illusion of control in the wild west of AI systems. It's a veritable checklist of 53 security risks that could totally happen, but you know, only if you're unlucky or something.
Let's dive into the riveting aspects this analysis will cover, shall we?
📌Security Risks Identification: Here, we'll pretend to be shocked at the discovery of vulnerabilities in AI systems. It's not like we ever thought these systems were bulletproof, right?
📌Control Measures: This is where we get to play hero by implementing those 53 magical steps that promise to keep the AI boogeyman at bay.
📌Deployment Models: We'll explore the various ways AI can be unleashed upon the world, because why not make things more complicated?
📌Integration with Existing Security Frameworks: Because reinventing the wheel is so last millennium, we'll see how DASF plays nice with other frameworks.
📌Practical Implementation: This is where we roll up our sleeves and get to work, applying the framework with the same enthusiasm as a kid doing chores.
And why, you ask, is this analysis a godsend for security professionals and other specialists? Well, it's not like they have anything better to do than read through another set of guidelines, right? Plus, it's always fun to align with regulatory requirements—it's like playing a game of legal Twister.
In all seriousness, this analysis will be as beneficial as a screen door on a submarine for those looking to safeguard their AI assets. By following the DASF, organizations can pretend to have a handle on the future, secure in the knowledge that they've done the bare minimum to protect their AI systems from the big, bad world out there.
-----
This document provides an in-depth analysis of the DASF, exploring its structure, recommendations, and the practical applications it offers to organizations implementing AI solutions. This analysis not only serves as a quality examination but also highlights its significance and practical benefits for security experts and professionals across different sectors. By implementing the guidelines and controls recommended by the DASF, organizations can safeguard their AI assets against emerging threats and vulnerabilities.
SECURE SERVICES: INTEGRATING SECURITY DIMENSION INTO THE SA&D cscpconf
Services security is often assimilated to a set of software solutions (Firewall, data encryption.) but rarely consider the organizational security rules as a fundamental part of the Services security policy. With the increasing use of new Services architectures (Open Services architecture, distributed database, multi web server, multi-tier application servers) security leaks become crucial and every security problem is harmful to the organization business continuity. To reduce and detect major security risks at an earlier step of the Services project, our approach is based on different knowledge exchange between end users, analyst, designers and developers collaborating at the Services project. The knowledge is mainly oriented to the detection of weak signals inside the organization. In this paper, we present the different knowledge surroundings an Services project and a knowledge pattern structure that can be used for the formalization aspects of the established exchange that should be established during the Services project between the different participants
US Government Software Assurance and Security InitiativesiLindsey Landolfi
This document provides an overview of software assurance (SwA) initiatives within the US federal government. It discusses how the Department of Homeland Security established the National Cyber Security Division Software Assurance Program to promote software security, integrity, and resiliency. It also describes the development of a common measurement framework to help organizations implement security best practices throughout the software development lifecycle. Finally, it analyzes security risks and mitigation strategies for Supervisory Control and Data Acquisition (SCADA) systems used in critical infrastructure through examples like the Stuxnet malware.
INTERFACE by apidays 2023 - Secure Software Development Framework (SSDF) & AP...apidays
INTERFACE by apidays 2023
APIs for a “Smart” economy. Embedding AI to deliver Smart APIs and turn into an exponential organization
June 28 & 29, 2023
Secure Software Development Framework (SSDF) & API Security
Bill Jones, Security Practice Director at Softrams
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
Cybersecurity is a compulsory, tough and expensive task for all organizations, private and public, large , medium and small.
No one can ignore it anymore, and building a viable Cybersecurity strategy is a complex task that needs to balance budget, keeping up with attacker technologies, available skills and a plethora of expensive tools on the market.
Let's discus s on how available Opensource solutions may greatly help ours organizations to be more effective in implementing their Cybersecurity posture, while optimizing available budget.
Matteo Meucci Software Security in practice - Aiea torino - 30-10-2015Minded Security
Matteo Meucci did a talk on software security in practice, describing the actual scenario and the roadmap for the enterprise to improve their maturity in the SDLC.
Building a Product Security Practice in a DevOps WorldArun Prabhakar
This document discusses building a product security practice in a DevOps world. It outlines key product security capabilities that enterprises should establish throughout the product lifecycle, including threat modeling, secure coding, software composition analysis, penetration testing, and continuous monitoring. It also discusses the importance of establishing governance around product security through defining roles, processes, and controls for different functions like business, operations, and security. The goal is to integrate software and product lifecycles in a coherent manner so that final products are secure without slowing down development.
This article will look at common mistakes that organizations make on the path to achieving vulnerability management perfection, both in process and technology areas.
3 Misconceptions Ruining The DevSecOps IntegrationEnov8
Every IT company aspires to be on every media agency's "hot news" and "latest headline" section, but not with such negative news. That's why DevSecOps security was introduced.
Agile development methods are commonly used to iteratively develop the information systems and they can
easily handle ever-changing business requirements. Scrum is one of the most popular agile software
development frameworks. The popularity is caused by the simplified process framework and its focus on
teamwork. The objective of Scrum is to deliver working software and demonstrate it to the customer faster
and more frequent during the software development project. However the security requirements for the
developing information systems have often a low priority. This requirements prioritization issue results in
the situations where the solution meets all the business requirements but it is vulnerable to potential
security threats.
The major benefit of the Scrum framework is the iterative development approach and the opportunity to
automate penetration tests. Therefore the security vulnerabilities can be discovered and solved more often
which will positively contribute to the overall information system protection against potential hackers.
In this research paper the authors propose how the agile software development framework Scrum can be
enriched by considering the penetration tests and related security requirements during the software
development lifecycle. Authors apply in this paper the knowledge and expertise from their previous work
focused on development of the new information system penetration tests methodology PETA with focus on
using COBIT 4.1 as the framework for management of these tests, and on previous work focused on
tailoring the project management framework PRINCE2 with Scrum.
The outcomes of this paper can be used primarily by the security managers, users, developers and auditors.
The security managers may benefit from the iterative software development approach and penetration tests
automation. The developers and users will better understand the importance of the penetration tests and
they will learn how to effectively embed the tests into the agile development lifecycle. Last but not least the
auditors may use the outcomes of this paper as recommendations for companies struggling with
penetrations testing embedded in the agile software development process.
Comparitive Analysis of Secure SDLC ModelsIRJET Journal
The document compares three secure software development lifecycle (SDLC) models: McGraw's Touchpoints, OWASP's CLASP, and Microsoft's Security Development Lifecycle (SDL). It summarizes each model, noting that Touchpoints has 7 activities, CLASP has 24 activities, and SDL has 16 core activities. The document then compares the models based on number of activities, activity dependence, nature (heavyweight vs lightweight), and suitability for organization size. Overall, it provides a high-level overview and comparison of three approaches to incorporating security practices into the SDLC.
2008: Web Application Security TutorialNeil Matatall
This document discusses web application security and summarizes key topics from a presentation on the subject. It introduces the Open Web Application Security Project (OWASP) Top 10 list of vulnerabilities, covering Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) in more detail. It also discusses security frameworks like ISO 27001 and the Payment Card Industry Data Security Standard (PCI DSS). The presentation emphasizes the importance of validating all user input to prevent injection attacks.
Assignment You will conduct a systems analysis project by .docxfestockton
Assignment:
You will conduct a systems analysis project by performing 3 phases of SDLC (planning, analysis and
design) for a small (real or imaginary) organization. The actual project implementation is not
required. You need to apply what you have learned in the class and to participate in the team
project work.
Deliverables
This project should follow the main steps of the first three phases of the SDLC (phase 1, 2 and 3).
Details description and diagrams should be included in each phase.
1- Planning:
Should cover the following:
• Project Initiation: How will it lowers costs or increase revenues?
• Project management: the project manager creates a work plan, staffs the project, and puts
techniques in place to help the project team control and direct the project through the
entire SDLC.
2- Analysis
Should cover the following:
• Analysis strategy: This is developed to guide the projects team’s efforts. This includes an
analysis of the current system.
• Requirements gathering: The analysis of this information leads to the development of a
concept for a new system. This concept is used to build a set of analysis models.
• System proposal: The proposal is presented to the project sponsor and other key
individuals who decide whether the project should continue to move forward.
3- Design
Should cover the following:
• Design Strategy: This clarifies whether the system will be developed by the company or
outside the company.
• Architecture Design: This describes the hardware, software, and network infrastructure that
will be used.
• Database and File Specifications: These documents define what and where the data will be
stored.
• Program Design: Defines what programs need to be written and what they will do.
The Course Presentations can be downloaded from here:
https://seu2020.com/wp-content/uploads/2019/09/Slides-IT243-Seu2020.com_.zip
In addition to the above please include
Points to be covered:
• Project Plan
• Staff Plan
• Cost
• Who will develop it? Self or vendor
• Project Methodology: need to consider the below factors when choosing a methodology
Clarity of User Requirements, Familiarity with Technology, System Complexity, System
Reliability, Short Time Schedules and Schedule Visibility
• Project timeline and timeframe.
• Risk Management
• Gantt Chart
• Project Requirements: Functional and Non-Functional
• Activity-Based Costing
• Outcome Analysis
• Technology Analysis
https://seu2020.com/wp-content/uploads/2019/09/Slides-IT243-Seu2020.com_.zip
• Include use cases
• Include Processing Model
• Data flow diagrams
• Relationship among Levels of DFDs
• Using the ERD to Show Business Rules
Please consider the slides as a reference of what topics to be covered for this assignment which falls
under the (planning, analysis and design) only.
Special Publication 800-86
Guide to Integrating Forensic
Techniques into Inciden ...
This document summarizes a report on processes for producing secure software. It discusses the problem of software vulnerabilities causing security issues, and the need for software developers to adopt processes that can measurably reduce defects and produce more secure software. The report's recommendations include adopting more effective development practices in the short-term, establishing a program to evaluate practices for producing secure software in the mid-term, and certifying effective processes and broadening related research and teaching in the long-term. The goal is to motivate software producers to implement practices that can be shown to reduce security vulnerabilities.
National Institute of Standards and Technology (NIST) Cybersecurity Framework...MichaelBenis1
The National Institute of Standards and Technology (NIST) has released version 2.0 of its landmark Cybersecurity Framework (NIST CSF). This framework is a comprehensive set of guidelines, best practices, and standards designed to help organizations manage and reduce cybersecurity risks. It is widely regarded as one of the most important resources for cybersecurity professionals, providing a roadmap for improving cybersecurity posture across various sectors.
The NIST Cybersecurity Framework was first introduced in 2014 in response to Executive Order 13636, which called for the development of a voluntary framework to improve cybersecurity in critical infrastructure. Since then, the framework has been widely adopted by organizations in both the public and private sectors, serving as a valuable tool for managing cybersecurity risks.
This document provides an overview of application security challenges and trends. It discusses how attacks have moved to target applications directly rather than just infrastructure. It also notes that security is often an afterthought for developers focused on speed and that maturity varies. Key trends include shifting security left in the development process, addressing open source risks, and leveraging tools like machine learning. Stakeholders have different priorities around protecting the organization versus meeting deadlines. Primary use cases involve finding and fixing vulnerabilities throughout the development lifecycle. The Fortify platform aims to provide application security that scales with development needs.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
20 Comprehensive Checklist of Designing and Developing a WebsitePixlogix Infotech
Dive into the world of Website Designing and Developing with Pixlogix! Looking to create a stunning online presence? Look no further! Our comprehensive checklist covers everything you need to know to craft a website that stands out. From user-friendly design to seamless functionality, we've got you covered. Don't miss out on this invaluable resource! Check out our checklist now at Pixlogix and start your journey towards a captivating online presence today.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIVladimir Iglovikov, Ph.D.
Presented by Vladimir Iglovikov:
- https://www.linkedin.com/in/iglovikov/
- https://x.com/viglovikov
- https://www.instagram.com/ternaus/
This presentation delves into the journey of Albumentations.ai, a highly successful open-source library for data augmentation.
Created out of a necessity for superior performance in Kaggle competitions, Albumentations has grown to become a widely used tool among data scientists and machine learning practitioners.
This case study covers various aspects, including:
People: The contributors and community that have supported Albumentations.
Metrics: The success indicators such as downloads, daily active users, GitHub stars, and financial contributions.
Challenges: The hurdles in monetizing open-source projects and measuring user engagement.
Development Practices: Best practices for creating, maintaining, and scaling open-source libraries, including code hygiene, CI/CD, and fast iteration.
Community Building: Strategies for making adoption easy, iterating quickly, and fostering a vibrant, engaged community.
Marketing: Both online and offline marketing tactics, focusing on real, impactful interactions and collaborations.
Mental Health: Maintaining balance and not feeling pressured by user demands.
Key insights include the importance of automation, making the adoption process seamless, and leveraging offline interactions for marketing. The presentation also emphasizes the need for continuous small improvements and building a friendly, inclusive community that contributes to the project's growth.
Vladimir Iglovikov brings his extensive experience as a Kaggle Grandmaster, ex-Staff ML Engineer at Lyft, sharing valuable lessons and practical advice for anyone looking to enhance the adoption of their open-source projects.
Explore more about Albumentations and join the community at:
GitHub: https://github.com/albumentations-team/albumentations
Website: https://albumentations.ai/
LinkedIn: https://www.linkedin.com/company/100504475
Twitter: https://x.com/albumentations
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
1. NIST CYBERSECURITY WHITE PAPER CSRC.NIST.GOV
Mitigating the Risk of Software
Vulnerabilities by Adopting a Secure
Software Development Framework (SSDF)
Donna Dodson
Applied Cybersecurity Division
Information Technology Laboratory
Murugiah Souppaya
Computer Security Division
Information Technology Laboratory
Karen Scarfone
Scarfone Cybersecurity
Clifton, VA
April 23, 2020
This publication is available free of charge from:
https://doi.org/10.6028/NIST.CSWP.04232020
2. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
ii
Abstract
Few software development life cycle (SDLC) models explicitly address software security in detail,
so secure software development practices usually need to be added to each SDLC model to ensure
the software being developed is well secured. This white paper recommends a core set of high-
level secure software development practices called a secure software development framework
(SSDF) to be integrated within each SDLC implementation. The paper facilitates communications
about secure software development practices among business owners, software developers, project
managers and leads, and cybersecurity professionals within an organization. Following these
practices should help software producers reduce the number of vulnerabilities in released software,
mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and
address the root causes of vulnerabilities to prevent future recurrences. Also, because the
framework provides a common vocabulary for secure software development, software consumers
can use it to foster communications with suppliers in acquisition processes and other management
activities.
Keywords
secure software development; secure software development framework (SSDF); secure software
development practices; software acquisition; software development; software development life
cycle (SDLC); software security.
Disclaimer
Any mention of commercial products or reference to commercial organizations is for information
only; it does not imply recommendation or endorsement by NIST, nor does it imply that the
products mentioned are necessarily the best available for the purpose.
Additional Information
For additional information on NIST’s Cybersecurity programs, projects and publications, visit the
Computer Security Resource Center. Information on other efforts at NIST and in the Information
Technology Laboratory (ITL) is also available.
Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Email: ssdf@nist.gov
All comments are subject to release under the Freedom of Information Act (FOIA).
3. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
iii
Acknowledgments
The authors wish to thank all of the individuals and organizations who provided comments on the
preliminary ideas and drafts, particularly BSA | The Software Alliance, the Information Security
and Privacy Advisory Board (ISPAB), and the members of the Software Assurance Forum for
Excellence in Code (SAFECode).
The authors also greatly appreciate the thoughtful public comments submitted by many
organizations and individuals, including the Administrative Offices of the U.S. Courts, The
Aerospace Corporation, BSA | The Software Alliance, Capitis Solutions, the Consortium for
Information & Software Quality (CISQ), HackerOne, Honeycomb Secure Systems, iNovex, Ishpi
Information Technologies, Juniper Networks, Medical Imaging & Technology Alliance (MITA),
Microsoft, Naval Sea Systems Command (NAVSEA), the National Institute of Standards and
Technology (NIST), Northrop Grumman, Office of the Undersecretary of Defense for Research
and Engineering, RedHat, SAFECode, and the Software Engineering Institute (SEI).
Audience
There are two primary audiences for this white paper. The first is software producers (e.g.,
commercial-off-the-shelf [COTS] product vendors, government-off-the-shelf [GOTS] software
developers, custom software developers) regardless of size, sector, or level of maturity. The second
is software consumers, both federal government agencies and other organizations. Readers of this
document are not expected to be experts in secure software development in order to understand it,
but such expertise is required to implement its recommended practices.
Personnel within the following Workforce Categories and Specialty Areas from the National
Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework [1] are most
likely to find this publication of interest:
• Securely Provision (SP): Risk Management (RSK), Software Development (DEV),
Systems Requirements Planning (SRP), Test and Evaluation (TST), Systems Development
(SYS)
• Operate and Maintain (OM): Systems Analysis (ANA)
• Oversee and Govern (OV): Training, Education, and Awareness (TEA); Cybersecurity
Management (MGT); Executive Cyber Leadership (EXL); Program/Project Management
(PMA) and Acquisition
• Protect and Defend (PR): Incident Response (CIR), Vulnerability Assessment and
Management (VAM)
• Analyze (AN): Threat Analysis (TWA), Exploitation Analysis (EXP)
Trademark Information
All registered trademarks or trademarks belong to their respective organizations.
4. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
1
1 Introduction
A software development life cycle (SDLC)1
is a formal or informal methodology for designing,
creating, and maintaining software (which includes code built into hardware). There are many
models for SDLCs, including waterfall, spiral, agile, and development and operations (DevOps).
Few SDLC models explicitly address software security in detail, so secure software development
practices usually need to be added to and integrated within each SDLC model. Regardless of which
SDLC model is used to develop software, secure software development practices should be
integrated throughout it for three reasons: to reduce the number of vulnerabilities in released
software, to mitigate the potential impact of the exploitation of undetected or unaddressed
vulnerabilities, and to address the root causes of vulnerabilities to prevent future recurrences. Most
aspects of security can be addressed at multiple places within an SDLC, but 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, also known as shifting left, is critically important regardless
of the SDLC model.
There are many existing documents on secure software development practices, including those
listed in the References section. This white paper does not introduce new practices or define new
terminology; instead, it describes a subset of high-level practices based on established standards,
guidance, and secure software development practice documents. These practices, collectively
called a secure software development framework (SSDF), should be particularly helpful for the
target audiences to achieve secure software development objectives. Note that these practices are
limited to those that bear directly on secure software development (e.g., securing the development
infrastructure or pipeline itself is out of scope).
This white paper is intended to be a starting point for discussing the concept of an SSDF and
therefore does not provide a comprehensive view of SSDFs. Future work may expand on the
material in this white paper, potentially covering topics such as how an SSDF may apply to and
vary for different software development methodologies and how an organization can transition
from using just their current software development practices to also incorporating the practices
specified by the SSDF. It is likely that future work will primarily take the form of use cases so that
the insights will be more readily applicable to certain types of development environments.
This white paper expresses secure software development practices but does not prescribe exactly
how to implement them. The focus is on implementing the practices rather than on the tools,
techniques, and mechanisms used to do so. For example, one organization might automate a
particular step, while another might use manual processes instead. Advantages of specifying the
practices at a high level include the following:
• Can be used by organizations in any sector or community, regardless of size or
cybersecurity sophistication
• Can be applied to software developed to support information technology (IT), industrial
control systems (ICS), cyber-physical systems (CPS), or the Internet of Things (IoT)
1
Note that SDLC is also widely used for “system development life cycle.” All usage of “SDLC” in this white paper is
referencing software, not systems.
5. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
2
• Can be integrated into any existing software development workflow and automated
toolchain; should not negatively affect organizations that already have robust secure
software development practices in place
• Makes the practices broadly applicable, not specific to particular technologies, platforms,
programming languages, SDLC models, development environments, operating
environments, tools, etc.
• Can help an organization document its secure software development practices today and
define its future target practices as part of its continuous improvement process
• Can assist an organization currently using a classic software development model in
transitioning its secure software development practices for use with a modern software
development model (e.g., agile, DevOps)
• Can assist organizations that are procuring and using software to understand secure
software development practices employed by their suppliers
This white paper also provides a common language to describe fundamental secure software
development practices. This is similar to the approach of the Framework for Improving Critical
Infrastructure Cybersecurity, also known as the NIST Cybersecurity Framework [2].2
Expertise
in secure software development is not required to understand the practices. This helps facilitate
communications about secure software practices among both internal and external organizational
stakeholders, such as the following:
• Business owners, software developers, project managers and leads, and cybersecurity
professionals within an organization
• Software consumers, including both federal government agencies and other organizations,
that want to define required or desired characteristics for software in their acquisition
processes in order to have higher-quality software (particularly with fewer security
vulnerabilities)3
• Software producers (e.g., commercial-off-the-shelf [COTS] product vendors, government-
off-the-shelf [GOTS] software developers, software developers working within or on
behalf of software consumer organizations, software testers/quality assurance personnel)
that want to integrate secure software development practices throughout their SDLCs,
express their secure software practices to their customers, or define requirements for their
suppliers
This white paper’s practices are not based on the assumption that all organizations have the same
security objectives and priorities; rather, the recommendations reflect that each software producer
may have unique security assumptions, and each software consumer may have unique security
needs and requirements. While the desire is for each software producer to follow all applicable
practices, the expectation is that the degree to which each practice is implemented and the formality
of the implementation will vary based on the producer’s security assumptions. The practices
2
The SSDF practices may help support the NIST Cybersecurity Framework Functions, Categories, and Subcategories, but the
SSDF practices do not map to them and are typically the responsibility of different parties. Developers can adopt SSDF
practices, and the outcomes of their work could help organizations with their operational security in support of the
Cybersecurity Framework.
3
Future work may provide more practical guidance for software consumers on how they can leverage the SSDF in specific use
cases.
6. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
3
provide flexibility for implementers, but they are also clear to avoid leaving too much open to
interpretation.
7. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
4
2 Secure Software Development Framework (SSDF)
This white paper introduces a software development framework (SSDF) of fundamental, sound,
and secure software development practices based on established secure software development
practice documents. For the purposes of this white paper, the practices are organized into four
groups:
• Prepare the Organization (PO): Ensure that the organization’s people, processes, and
technology are prepared to perform secure software development at the organization level
and, in some cases, for each individual project.
• Protect the Software (PS): Protect all components of the software from tampering and
unauthorized access.
• Produce Well-Secured Software (PW): Produce well-secured software that has minimal
security vulnerabilities in its releases.
• Respond to Vulnerabilities (RV): Identify vulnerabilities in software releases and
respond appropriately to address those vulnerabilities and prevent similar vulnerabilities
from occurring in the future.
Each practice is defined with the following elements:
• Practice: A brief statement of the practice, along with a unique identifier and an
explanation of what the practice is and why it is beneficial.
• Task: An individual action (or actions) needed to accomplish a practice.
• Implementation Example: An example of a type of tool, process, or other method that
could be used to implement this practice; not intended to imply that any example or
combination of examples is required or that only the stated examples are feasible options.
• Reference: An established secure development practice document and its mappings to a
particular task.
Although most practices are relevant for any software development effort, some practices are not
always applicable. For example, if developing a particular piece of software does not involve using
a compiler, there would be no need to follow a practice on configuring the compiler to improve
executable security. Some practices are more fundamental, while others are more advanced and
may depend on certain fundamental practices already being in place. Also, practices are not all
equally important in any particular case. Risk should be considered when deciding which practices
to use and how much time and resources to devote to each practice.4
Finally, the frequency for
performing recurring practices is not specified because the frequency appropriate for any particular
situation depends on risk and other factors.
The table that defines the practices is below. Remember that these practices are only a subset of
what an organization may need to do, with the practices focused on helping organizations achieve
secure software development objectives. The practices are not listed sequentially or in order of
4
Organizations seeking guidance on how to get started with secure software development can consult many publicly available
references, such as “SDL That Won’t Break the Bank” by Steve Lipner from SAFECode (https://i.blackhat.com/us-18/Thu-
August-9/us-18-Lipner-SDL-For-The-Rest-Of-Us.pdf) and “Simplified Implementation of the Microsoft SDL” by Microsoft
(https://www.microsoft.com/en-us/download/details.aspx?id=12379).
8. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
5
importance. The information in the table is space constrained, and much more information on each
practice can be found in the references (with the bolded text on each line being the identifier used
for that reference in the table):
• BSIMM10: Building Security in Maturity Model (BSIMM) Version 10 [3]
• BSA: BSA, Framework for Secure Software [4]
• IDASOAR: Institute for Defense Analyses (IDA), State-of-the-Art Resources (SOAR) for
Software Vulnerability Detection, Test, and Evaluation 2016 [5]
• ISO27034: International Organization for Standardization/International Electrotechnical
Commission (ISO/IEC), Information technology – Security techniques – Application
security – Part 1: Overview and concepts, ISO/IEC 27034-1:2011 [6]
• MSSDL: Microsoft, Security Development Lifecycle [7]
• NISTCSF: NIST, Framework for Improving Critical Infrastructure Cybersecurity,
Version 1.1 [2]
• OWASPASVS: OWASP, OWASP Application Security Verification Standard 4.0 [8]
• OWASPTEST: OWASP, OWASP Testing Guide 4.0 [9]
• PCISSLRAP: Payment Card Industry (PCI) Security Standards Council, Secure Software
Lifecycle (Secure SLC) Requirements and Assessment Procedures Version 1.0 [10]
• SAMM15: OWASP, Software Assurance Maturity Model Version 1.5 [11]
• SCAGILE: Software Assurance Forum for Excellence in Code (SAFECode), Practical
Security Stories and Security Tasks for Agile Development Environments [12]
• SCFPSSD: SAFECode, Fundamental Practices for Secure Software Development:
Essential Elements of a Secure Development Lifecycle Program, Third Edition [13]
• SCSIC: SAFECode, Software Integrity Controls: An Assurance-Based Approach to
Minimizing Risks in the Software Supply Chain [14]
• SCTPC: SAFECode, Managing Security Risks Inherent in the Use of Third-Party
Components [15]
• SCTTM: SAFECode, Tactical Threat Modeling [16]
• SP80053: Joint Task Force Transformation Initiative, Security and Privacy Controls for
Federal Information Systems and Organizations, NIST Special Publication (SP) 800-53
Revision 4 [17]
• SP800160: NIST, Systems Security Engineering: Considerations for a Multidisciplinary
Approach in the Engineering of Trustworthy Secure Systems, NIST SP 800-160 Volume 1
[18]
• SP800181: NIST, National Initiative for Cybersecurity Education (NICE) Cybersecurity
Workforce Framework, NIST SP 800-181 [1]
9. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
6
Practices Tasks Implementation Examples References
Prepare the Organization (PO)
Define Security Requirements
for Software Development
(PO.1): Ensure that security
requirements for software
development are known at all
times so that they can be taken
into account throughout the
SDLC and duplication of effort
can be minimized because the
requirements information can be
collected once and shared. This
includes requirements from
internal sources (e.g., the
organization’s policies, business
objectives, and risk
management strategy) and
external sources (e.g.,
applicable laws and regulations).
PO.1.1: Identify all applicable
security requirements for the
organization’s general software
development, and maintain the
requirements over time.
• Define policies that specify the security
requirements for the organization’s
software to meet, including secure
coding practices for developers to follow.
• Define policies that specify software
architecture requirements, such as
making code modular to facilitate code
reuse and easier updates as well as
isolating security functionality from other
functionality during code execution.
• Define policies for securing the
development infrastructure, such as
developer workstations and code
repositories.
• Ensure that policies cover the entire
software life cycle, including notifying
users of the impending end of software
support and the date of software end-of-
life.
• Use a well-known set of security
requirements as a structure or lexicon for
defining the organization’s requirements.
This set can be mapped to other third-
party security requirements to which the
organization is also subject.
• Review and update the requirements
after each response to a vulnerability
incident.
• Conduct a periodic (typically at least
annual) review of all security
requirements.
• Promptly review new external
requirements and updates to existing
external requirements.
• Educate affected individuals on the
impending changes in requirements.
BSIMM10: CP1.1, CP1.3, SR1.1
BSA: SC.1-1, SC.2, PD.1-1, PD.1-2,
PD.1-3, PD.2-2
ISO27034: 7.3.2
MSSDL: Practice 2
NISTCSF: ID.GV-3
OWASPTEST: Phase 2.1
PCISSLRAP: 2.1
SAMM15: PC1-A, PC1-B, PC2-A, SR1-
A, SR1-B, SR2-B
SCFPSSD: Planning the Implementation
and Deployment of Secure Development
Practices; Establish Coding Standards
and Conventions
SP80053: SA-15
SP800160: 3.1.2, 3.3.1, 3.4.2, 3.4.3
SP800181: T0414; K0003, K0039,
K0044, K0157, K0168, K0177, K0211,
K0260, K0261, K0262, K0524; S0010,
S0357, S0368; A0033, A0123, A0151
10. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
7
Practices Tasks Implementation Examples References
Implement Roles and
Responsibilities (PO.2):
Ensure that everyone inside and
outside of the organization
involved in the SDLC is
prepared to perform their SSDF-
related roles and responsibilities
throughout the SDLC.
PO.2.1: Create new roles and
alter responsibilities for existing
roles to encompass all parts of
the SSDF. Periodically review
the defined roles and
responsibilities, and update
them as needed.
• Define SSDF-related roles and
responsibilities for all members of the
software development team.
• Integrate the security roles into the
software development team.
• Define roles and responsibilities for
cybersecurity staff, security champions,
project managers and leads, senior
management, software developers,
software testers/quality assurance
personnel, product owners, and others
involved in the SDLC.
• Conduct an annual review of all roles
and responsibilities.
• Educate affected individuals on the
impending changes in roles and
responsibilities.
BSA: PD.2-1, PD.2-2
BSIMM10: CP3.2, SM1.1
NISTCSF: ID.AM-6, ID.GV-2
PCISSLRAP: 1.2
SCSIC: Vendor Software Development
Integrity Controls
SP80053: SA-3
SP800160: 3.2.1, 3.2.4, 3.3.1
SP800181: K0233
PO.2.2: Provide role-specific
training for all personnel with
responsibilities that contribute to
secure development.
Periodically review role-specific
training and update it as
needed.
• Document the desired outcomes of
training for each role.
• Create a training plan for each role.
• Acquire or create training for each role;
acquired training may need
customization for the organization.
BSA: PD.2-2
BSIMM10: CP2.5, SM1.3, T1.1, T1.5,
T1.7, T2.6, T2.8, T3.2, T3.4
MSSDL: Practice 1
NISTCSF: PR.AT-*
PCISSLRAP: 1.3
SAMM15: EG1-A, EG2-A
SCAGILE: Operational Security Tasks
14, 15; Tasks Requiring the Help of
Security Experts 1
SCFPSSD: Planning the Implementation
and Deployment of Secure Development
Practices
SCSIC: Vendor Software Development
Integrity Controls
SP80053: SA-8
SP800160: 3.2.4
SP800181: OV-TEA-001, OV-TEA-002;
T0030, T0073, T0320; K0204, K0208,
K0220, K0226, K0243, K0245, K0252;
S0100, S0101; A0004, A0057
11. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
8
Practices Tasks Implementation Examples References
PO.2.3: Obtain upper
management commitment to
secure development, and
convey that commitment to all
with SSDF-related roles and
responsibilities.
• Increase awareness by upper
management.
• Assist upper management in
incorporating secure development
support into their communications with
personnel with SSDF-related roles and
responsibilities.
• Educate all personnel with SSDF-related
roles and responsibilities on upper
management’s commitment to the SSDF
and the importance of the SSDF to the
organization.
BSIMM10: SM1.2, SM1.3
PCISSLRAP: 1.1
SAMM15: SM1.A
SP 800-181: T0001, T0004
Implement a Supporting
Toolchain (PO.3): Use
automation to reduce the human
effort needed and improve the
accuracy, consistency, and
comprehensiveness of security
practices throughout the SDLC,
as well as provide a way to
document and demonstrate use
of these practices. Toolchains
and tools may be used at
different levels of the
organization, such as
organization-wide or project-
specific.
PO.3.1: Specify which tools or
tool types are to be included in
each toolchain and which are
mandatory, as well as how the
toolchain components are to be
integrated with each other.
• Define categories of toolchains, and
specify the mandatory tools or tool types
to be used for each category.
• Identify security tools to integrate into the
developer toolchain.
• Use automated technology for toolchain
management and orchestration.
BSA: TC.1, TC.1-1, TC.1-2
MSSDL: Practice 8
SCAGILE: Tasks Requiring the Help of
Security Experts 9
SP80053: SA-15
SP800181: K0013, K0178
PO.3.2: Following sound
security practices, deploy and
configure tools, integrate them
within the toolchain, and
maintain the individual tools and
the toolchain as a whole.
• Evaluate, select, and acquire tools, and
assess the security of each tool.
• Integrate tools with other tools and with
existing software development
processes and workflows.
• Update, upgrade, and replace existing
tools.
• Monitor tools and tool logs for potential
operational and security issues.
BSA: TC.1-1, TC.1-6
SCAGILE: Tasks Requiring the Help of
Security Experts 9
SP80053: SA-15
SP800181: K0013, K0178
PO.3.3: Configure tools to
collect evidence and artifacts of
their support of the secure
software development practices.
• Use the organization’s existing workflow
or issue tracking systems to create an
audit trail of the secure development-
related actions that are performed.
• Determine how often the collected
information should be audited, and
implement processes to perform the
auditing.
BSA: PD.1.6
MSSDL: Practice 8
PCISSLRAP: 2.5
SCAGILE: Tasks Requiring the Help of
Security Experts 9
SP80053: SA-15
SP800181: K0013
12. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
9
Practices Tasks Implementation Examples References
Define Criteria for Software
Security Checks (PO.4): Help
ensure that the software
resulting from the SDLC meets
the organization’s expectations
by defining criteria for checking
the software’s security during
development.
PO.4.1: Define criteria for
software security checks
throughout the SDLC.
• Ensure that the criteria adequately
indicate how effectively security risk is
being managed.
• Define key performance indicators
(KPIs) for software security.
• Add software security criteria to existing
checks (e.g., the Definition of Done in
agile SDLC methodologies).
• Review the artifacts generated as part of
the software development workflow
system to determine if they meet the
criteria purposes.
• Record security check approvals,
rejections, and requests for exception as
part of the workflow and tracking system.
BSA: TV.2-1, TV.5-1
BSIMM10: SM1.4, SM2.2
ISO27034: 7.3.5
MSSDL: Practice 3
OWASPTEST: Phase 1.3
SAMM15: DR3-B, IR3-B, PC3-A, ST3-B
SP80053: SA-15
SP800160: 3.2.1, 3.2.5, 3.3.1
SP800181: K0153, K0165
PO.4.2: Implement processes,
mechanisms, etc. to gather the
necessary information in support
of the criteria.
• Use the toolchain to automatically gather
information that informs security
decision-making.
• Deploy additional tools if needed to
support the generation and collection of
information supporting the criteria.
• Automate decision-making processes
utilizing the criteria.
BSA: PD.1-6
BSIMM10: SM1.4, SM2.2
SP80053: SA-15
SP800160: 3.3.7
SP800181: T0349; K0153
13. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
10
Practices Tasks Implementation Examples References
Protect Software (PS)
Protect All Forms of Code
from Unauthorized Access
and Tampering (PS.1): Help
prevent unauthorized changes
to code, both inadvertent and
intentional, which could
circumvent or negate the
intended security characteristics
of the software. For code that is
not intended to be publicly
accessible, it helps prevent theft
of the software and may make it
more difficult or time-consuming
for attackers to find
vulnerabilities in the software.
PS.1.1: Store all forms of code,
including source code and
executable code, based on the
principle of least privilege so that
only authorized personnel have
the necessary forms of access.
• Store all source code in a code
repository, and restrict access to it based
on the nature of the code. For example,
some code may be intended for public
access, in which case its integrity and
availability should be protected; other
code may also need its confidentiality
protected.
• Use version control features of the
repository to track all changes made to
the code with accountability to the
individual developer account.
• Review and approve all changes made
to the code.
• Use code signing to help protect the
integrity and provenance of executables.
• Use cryptography (e.g., cryptographic
hashes) to help protect the integrity of
files.
• Create and maintain a software bill of
materials (SBOM) for each software
package created.
BSA: IA.1, IA.2-2, SM.4-1
IDASOAR: Fact Sheet 25
NISTCSF: PR.AC-4
OWASPASVS: 1.10, 10.3.2, 14.2
PCISSLRAP: 6.1
SCSIC: Vendor Software Delivery
Integrity Controls, Vendor Software
Development Integrity Controls
Provide a Mechanism for
Verifying Software Release
Integrity (PS.2): Help software
consumers ensure that the
software they acquire is
legitimate and has not been
tampered with.
PS.2.1: Make verification
information available to software
consumers.
• Post cryptographic hashes for release
files on a well-secured website.
• Use an established certificate authority
for code signing so consumers can
confirm the validity of signatures.
• Periodically review the code signing
processes, including certificate renewal
and protection.
BSA: SM.4.2, SM.4.3, SM.5.1, SM.6.1
BSIMM10: SE2.4
NISTCSF: PR.DS-6
PCISSLRAP: 6.2
SAMM15: OE3-B
SCSIC: Vendor Software Delivery
Integrity Controls
SP800181: K0178
Archive and Protect Each
Software Release (PS.3): Help
identify, analyze, and eliminate
vulnerabilities discovered in the
software after release.
PS.3.1: Securely archive a copy
of each release and all of its
components (e.g., code,
package files, third-party
libraries, documentation), and
release integrity verification
information.
• Store all release files in a repository, and
restrict access to them.
BSA: PD.1-6
IDASOAR: Fact Sheet 25
NISTCSF: PR.IP-4
PCISSLRAP: 5.2, 6.2
SCSIC: Vendor Software Delivery
Integrity Controls
SP80053: SA-15
14. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
11
Practices Tasks Implementation Examples References
Produce Well-Secured Software (PW)
Design Software to Meet
Security Requirements and
Mitigate Security Risks
(PW.1): Identify and evaluate
the applicable security
requirements for the software’s
design; determine what security
risks the software is likely to
face during production operation
and how those risks should be
mitigated by the software’s
design; and justify any cases
where risk-based decisions
conclude that security
requirements should be relaxed
or waived. Addressing security
requirements and risks during
software design (secure by
design) helps to make software
development more efficient.
PW.1.1: Use forms of risk
modeling, such as threat
modeling, attack modeling, or
attack surface mapping, to help
assess the security risk for the
software.
• Train the development team (the security
champions in particular) or collaborate
with a threat modeling expert to create
threat models and attack models and to
analyze how to use a risk-based
approach to address the risks and
implement mitigations.
• Perform more rigorous assessments for
high-risk areas, such as protecting
sensitive data and safeguarding
identification, authentication, and access
control, including credential
management.
• Review vulnerability reports and
statistics for previous software.
BSA: SC.1-3, SC.1-4
BSIMM10: AM1.3, AM1.5, AM2.1,
AM2.2, AM2.5, AM2.6, AM2.7
IDASOAR: Fact Sheet 1
ISO27034: 7.3.3
MSSDL: Practice 4
NISTCSF: ID.RA-*
OWASPASVS: 1.1.2, 1.2, 1.4, 1.6, 1.8,
1.9, 1.11, 2, 3, 4, 6, 8, 9, 11, 12, 13
OWASPTEST: Phase 2.4
PCISSLRAP: 3.2
SAMM15: DR1-A, TA1-A, TA1-B, TA3-B
SCAGILE: Tasks Requiring the Help of
Security Experts 3
SCFPSSD: Threat Modeling
SCTTM: Entire guide
SP80053: SA-8, SA-15, SA-17
SP800160: 3.3.4, 3.4.5
SP800181: T0038, T0062, T0236;
K0005, K0009, K0038, K0039, K0070,
K0080, K0119, K0147, K0149, K0151,
K0152, K0160, K0161, K0162, K0165,
K0297, K0310, K0344, K0362, K0487,
K0624; S0006, S0009, S0022, S0078,
S0171, S0229, S0248; A0092, A0093,
A107
15. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
12
Practices Tasks Implementation Examples References
Review the Software Design
to Verify Compliance with
Security Requirements and
Risk Information (PW.2): Help
ensure that the software will
meet the security requirements
and satisfactorily address the
identified risk information.
PW.2.1: Have a qualified person
who was not involved with the
software design review it to
confirm that it meets all of the
security requirements and
satisfactorily addresses the
identified risk information.
• Review the software design to confirm
that it addresses all of the security
requirements.
• Review the risk models created during
software design to determine if they
appear to adequately identify the risks.
• Review the software design to confirm
that it satisfactorily addresses the risks
identified by the risk models.
• Have the software’s designer correct
failures to meet the requirements.
• Change the design and/or the risk
response strategy if the security
requirements cannot be met.
BSA: TV.3, TV.3-1, TV.5
BSIMM10: AA1.2, AA2.1
ISO27034: 7.3.3
OWASPTEST: Phase 2.2
SAMM15: DR1-A, DR1-B
SP800181: T0328; K0038, K0039,
K0070, K0080, K0119, K0152, K0153,
K0161, K0165, K0172, K0297; S0006,
S0009, S0022, S0036, S0141, S0171
Verify Third-Party Software
Complies with Security
Requirements (PW.3): Reduce
the risk associated with using
acquired software modules and
services, which are potential
sources of additional
vulnerabilities.
PW.3.1: Communicate
requirements to third parties
who may provide software
modules and services to the
organization for reuse by the
organization’s own software.
• Define a core set of security
requirements, and include them in
acquisition documents, software
contracts, and other agreements with
third parties.
• Define the security-related criteria for
selecting commercial and open-source
software.
• Require the providers of commercial
software modules and services to
provide evidence that their software
complies with the organization’s security
requirements.
• Establish and follow procedures to
address risk when there are security
requirements that third-party software
modules and services do not meet.
BSA: SM.1, SM.2, SM.2-1, SM.2.4
BSIMM10: CP2.4, SR2.5, SR3.2
IDASOAR: Fact Sheets 19, 21
MSSDL: Practice 7
SAMM15: SR3-A
SCFPSSD: Manage Security Risk
Inherent in the Use of Third-Party
Components
SCSIC: Vendor Sourcing Integrity
Controls
SP80053: SA-4, SA-12
SP800160: 3.1.1, 3.1.2
SP800181: T0203, T0415; K0039;
S0374; A0056, A0161
16. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
13
Practices Tasks Implementation Examples References
PW.3.2: Use appropriate means
to verify that commercial, open
source, and all other third-party
software modules and services
comply with the requirements.
• See if there are publicly known
vulnerabilities in the software modules
and services that the vendor has not yet
fixed.
• Ensure each software module or service
is still actively maintained, which should
include new vulnerabilities found in the
software being remediated.
• Determine a plan of action for each third-
party software module or service that is
no longer being maintained or available
in the future.
• Use the results of commercial services
for vetting the software modules and
services.
• [See Review and/or Analyze Human-
Readable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.7)]
• [See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
BSA: SC.3-1, TV.2
IDASOAR: Fact Sheet 21
MSSDL: Practice 7
OWASPASVS: 10, 14.2
PCISSLRAP: 4.1
SCAGILE: Tasks Requiring the Help of
Security Experts 8
SCFPSSD: Manage Security Risk
Inherent in the Use of Third-Party
Components
SCSIC: Vendor Sourcing Integrity
Controls
SCTPC: 3.2.2
SP80053: SA-12
SP800160: 3.1.2, 3.3.8
SP800181: SP-DEV-002; K0153, K0266
[See Review and/or Analyze Human-
Readable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.7)]
[See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
Reuse Existing, Well-Secured
Software When Feasible
Instead of Duplicating
Functionality (PW.4): Lower
the costs of software
development, expedite software
development, and decrease the
likelihood of introducing
additional security vulnerabilities
into the software. These are
particularly true for software that
implements security
functionality, such as
cryptographic modules and
protocols.
PW.4.1: Acquire well-secured
components (e.g., software
libraries, modules, middleware,
frameworks) from third parties
for use by the organization’s
software.
• Review and evaluate third-party software
components in the context of their
expected use. If a component is to be
used in a substantially different way in
the future, perform the review and
evaluation again with that new context in
mind.
• Establish an organization-wide software
repository to host sanctioned and vetted
open-source components.
• Maintain a list of organization-approved
commercial software components and
component versions.
• Designate which components must be
included by software to be developed.
BSA: SM.2, SM.2.1
IDASOAR: Fact Sheet 19
MSSDL: Practice 6
SAMM15: SA1-A
SCTPC: 3.2.1
SP80053: SA-12
SP800181: K0039
17. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
14
Practices Tasks Implementation Examples References
PW.4.2: Create well-secured
software components in-house
following SDLC processes to
meet common internal software
development needs that cannot
be better met by third-party
software.
• Follow the organization-established
security practices for secure software
development.
• Maintain an organization-wide software
repository for these components.
• Designate which components must be
included by software to be developed.
BSIMM10: SFD1.1, SFD2.1
IDASOAR: Fact Sheet 19
OWASPASVS: 10
SP800181: SP-DEV-001
PW.4.3: Where appropriate,
build in support for using
standardized security features
and services (e.g., integrating
with log management, identity
management, access control,
and vulnerability management
systems) instead of creating
proprietary implementations of
security features and services.
• Maintain an organization-wide software
repository of modules for supporting
standardized security features and
services.
• Designate which security features and
services must be supported by software
to be developed.
BSA: SI.2, EN.1-1, LO.1
MSSDL: Practice 5
OWASPASVS: 1.1.6
SCFPSSD: Establish Log Requirements
and Audit Practices
Create Source Code Adhering
to Secure Coding Practices
(PW.5): Decrease the number of
security vulnerabilities in the
software, and reduce costs by
eliminating vulnerabilities during
source code creation.
PW.5.1: Follow all secure
coding practices that are
appropriate to the development
languages and environment.
• Validate all inputs, and validate and
properly encode all output.
• Avoid using unsafe functions and calls.
• Handle errors gracefully.
• Provide logging and tracing capabilities.
• Use development environments with
features that encourage or require the
use of secure coding practices.
• Follow procedures for manually ensuring
compliance with secure coding practices.
• Check for other vulnerabilities that are
common to the development languages
and environment.
BSA: SC.2, SC.4, SC.3, SC.3-2, EE.1,
EE.1.2, EE.2, LO.1,
IDASOAR: Fact Sheet 2
ISO27034: 7.3.5
MSSDL: Practice 9
OWASPASVS: 1.5, 1.7, 5, 7,
SCFPSSD: Establish Log Requirements
and Audit Practices, Handle Data Safely,
Handle Errors, Use Safe Functions Only
SP800181: SP-DEV-001; T0013, T0077,
T0176; K0009, K0016, K0039, K0070,
K0140, K0624; S0019, S0060, S0149,
S0172, S0266; A0036, A0047
PW.5.2: Have the developer
review their own human-
readable code, analyze their
own human-readable code,
and/or test their own executable
code to complement (not
replace) code review, analysis,
and/or testing performed by
others.
• [See Review and/or Analyze Human-
Readable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.7)]
• [See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
[See Review and/or Analyze Human-
Readable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.7)]
[See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
18. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
15
Practices Tasks Implementation Examples References
Configure the Compilation
and Build Processes to
Improve Executable Security
(PW.6): Decrease the number of
security vulnerabilities in the
software, and reduce costs by
eliminating vulnerabilities before
testing occurs.
PW.6.1: Use compiler and build
tools that offer features to
improve executable security.
• Use up-to-date versions of compiler and
build tools.
• Validate the authenticity and integrity of
compiler and build tools.
BSA: TC.1-1, TC.1-3, TC.1-4, TC.1-5
MSSDL: Practice 8
SCAGILE: Operational Security Task 3
SCFPSSD: Use Current Compiler and
Toolchain Versions and Secure Compiler
Options
SCSIC: Vendor Software Development
Integrity Controls
PW.6.2: Determine which
compiler and build tool features
should be used and how each
should be configured, then
implement the approved
configuration for compilation and
build tools, processes, etc.
• Enable compiler features that produce
warnings for poorly secured code during
the compilation process.
• Implement the “clean build” concept,
where all compiler warnings are treated
as errors and eliminated.
• Enable compiler features that randomize
characteristics, such as memory location
usage, that would otherwise be easily
predictable and thus exploitable.
• Conduct testing to ensure that the
features are working as expected and
not inadvertently causing any operational
issues or other problems.
• Verify that the approved configuration is
enabled for compilation and build tools,
processes, etc.
• Document information about the
compilation and build tool configuration
in a knowledge base that developers can
access and search.
BSA: TC.1, TC.1-3, TC.1-4, TC.1-5
OWASPASVS: 1.14.3, 1.14.4, 14.1
SCAGILE: Operational Security Task 8
SCFPSSD: Use Current Compiler and
Toolchain Versions and Secure Compiler
Options
SCSIC: Vendor Software Development
Integrity Controls
SP800181: K0039, K0070
19. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
16
Practices Tasks Implementation Examples References
Review and/or Analyze
Human-Readable Code to
Identify Vulnerabilities and
Verify Compliance with
Security Requirements
(PW.7): Help identify
vulnerabilities so they can be
corrected before the software is
released to prevent exploitation.
Using automated methods
lowers the effort and resources
needed to detect vulnerabilities.
Human-readable code includes
source code and any other form
of code an organization deems
as human readable.
PW.7.1: Determine whether
code review (i.e., a person
directly looks at the code to find
issues) and/or code analysis
(i.e., tools are used to find
issues in code, either in a fully
automated way or in conjunction
with a person) should be used.
• Follow the organization’s policies or
guidelines for when code review should
be performed and how it should be
conducted. This includes third-party
code and reusable code modules written
in-house.
• Follow the organization’s policies or
guidelines for when code analysis should
be performed and how it should be
conducted.
SCSIC: Peer Reviews and Security
Testing
SP80053: SA-11
SP800181: SP-DEV-002; K0013, K0039,
K0070, K0153, K0165; S0174
PW.7.2: Perform the code
review and/or code analysis
based on the organization’s
secure coding standards, and
document and triage all
discovered issues and
recommended remediations in
the development team’s
workflow or issue tracking
system.
• Perform peer review of code, and review
any existing code review, analysis, or
testing results as part of the peer review.
• Use peer reviews to check code for
backdoors and other malicious content.
• Use peer reviewing tools that facilitate
the peer review process, and document
all discussions and other feedback.
• Use a static analysis tool to
automatically check code for
vulnerabilities and for compliance with
the organization’s secure coding
standards, with a human reviewing
issues reported by the tool and
remediating them as necessary.
• Use review checklists to verify that the
code complies with the requirements.
• Use automated tools to identify and
remediate documented and verified
unsafe software practices on a
continuous basis as human-readable
code is checked into the code repository.
• Identify and document the root cause of
each discovered issue.
• Document lessons learned from code
review and analysis in a knowledge base
that developers can access and search.
BSA: PD.1-5, TV.2, TV.3
BSIMM10: CR1.2, CR1.4, CR1.6,
CR2.6, CR2.7
IDASOAR: Fact Sheets 3, 4, 5, 14, 15,
48
ISO27034: 7.3.6
MSSDL: Practices 9, 10
OWASPASVS: 1.1.7, 10
OWASPTEST: Phase 3.2, Phase 4.1
PCISSLRAP: 4.1
SAMM15: IR1-B, IR2-A, IR2-B
SCAGILE: Operational Security Tasks 4,
7
SCFPSSD: Use Code Analysis Tools to
Find Security Issues Early, Use Static
Analysis Security Testing Tools, Perform
Manual Verification of Security
Features/Mitigations
SCSIC: Peer Reviews and Security
Testing
SP80053: SA-11, SA-15
SP800181: SP-DEV-001, SP-DEV-002;
T0013, T0111, T0176, T0267, T0516;
K0009, K0039, K0070, K0140, K0624;
S0019, S0060, S0078, S0137, S0149,
S0167, S0174, S0242, S0266; A0007,
A0015, A0036, A0044, A0047
20. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
17
Practices Tasks Implementation Examples References
Test Executable Code to
Identify Vulnerabilities and
Verify Compliance with
Security Requirements
(PW.8): Help identify
vulnerabilities so they can be
corrected before the software is
released in order to prevent
exploitation. Using automated
methods lowers the effort and
resources needed to detect
vulnerabilities. Executable code
includes binaries, directly
executed bytecode, directly
executed source code, and any
other form of code an
organization deems as
executable.
PW.8.1: Determine if executable
code testing should be
performed and, if so, which
types should be used.
• Follow the organization’s policies or
guidelines for when code testing should
be performed and how it should be
conducted. This includes third-party
executable code and reusable
executable code modules written in-
house.
BSA: TV.3
SCSIC: Peer Reviews and Security
Testing
SP80053: SA-11
SP800181: SP-DEV-001, SP-DEV-002;
T0456; K0013, K0039, K0070, K0153,
K0165, K0342, K0367, K0536, K0624;
S0001, S0015, S0026, S0061, S0083,
S0112, S0135
PW.8.2: Design the tests,
perform the testing, and
document the results.
• Perform robust functional testing of
security features.
• Integrate dynamic vulnerability testing
into the project’s automated test suite.
• Incorporate tests for previously reported
vulnerabilities into the project’s
automated test suite to ensure that
errors are not reintroduced.
• Use automated fuzz testing tools to find
issues with input handling.
• If resources are available, use
penetration testing to simulate how an
attacker might attempt to compromise
the software in high-risk scenarios.
• Identify and document the root cause of
each discovered issue.
• Document lessons learned from code
testing in a knowledge base that
developers can access and search.
BSA: PD.1-5, TV.3, TV.5, TV.5-2
BSIMM10: PT1.1, PT1.2, PT1.3, ST1.1,
ST1.3, ST2.1, ST2.4, ST2.5, ST2.6,
ST3.3, ST3.4
IDASOAR: Fact Sheets 7, 8, 10, 11, 38,
39, 43, 44, 48, 55, 56, 57
ISO27034: 7.3.6
MSSDL: Practice 11
PCISSLRAP: 4.1
SAMM15: ST1-B, ST2-A, ST2-B
SCAGILE: Operational Security Tasks
10, 11; Tasks Requiring the Help of
Security Experts 4, 6, 7
SCFPSSD: Perform Dynamic Analysis
Security Testing, Fuzz Parsers, Network
Vulnerability Scanning, Perform
Automated Functional Testing of
Security Features/Mitigations, Perform
Penetration Testing
SCSIC: Peer Reviews and Security
Testing
SP80053: SA-11, SA-15
SP800181: SP-DEV-001, SP-DEV-002;
T0013, T0028, T0169, T0176, T0253,
T0266, T0456, T0516; K0009, K0039,
K0070, K0272, K0339, K0342, K0362,
K0536, K0624; S0001, S0015, S0046,
S0051, S0078, S0081, S0083, S0135,
S0137, S0167, S0242; A0015
21. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
18
Practices Tasks Implementation Examples References
Configure the Software to
Have Secure Settings by
Default (PW.9): Help improve
the security of the software at
the time of installation to reduce
the likelihood of the software
being deployed with weak
security settings that would put it
at greater risk of compromise.
PW.9.1: Determine how to
configure each setting that has
an effect on security so that the
default settings are secure and
do not weaken the security
functions provided by the
platform, network infrastructure,
or services.
• Conduct testing to ensure that the
settings, including the default settings,
are working as expected and are not
inadvertently causing any security
weaknesses, operational issues, or other
problems.
BSA: CF.1, TC.1
IDASOAR: Fact Sheet 23
ISO27034: 7.3.5
OWASPTEST: Phase 4.2
SCAGILE: Tasks Requiring the Help of
Security Experts 12
SCSIC: Vendor Software Delivery
Integrity Controls, Vendor Software
Development Integrity Controls
SP800181: SP-DEV-002; K0009, K0039,
K0073, K0153, K0165, K0275, K0531;
S0167
PW.9.2: Implement the default
settings (or groups of default
settings, if applicable), and
document each setting for
software administrators.
• Verify that the approved configuration is
in place for the software.
• Document each setting’s purpose,
options, default value, security
relevance, potential operational impact,
and relationships with other settings.
• Document how each setting can be
implemented by software administrators.
IDASOAR: Fact Sheet 23
OWASPTEST: Phase 4.2
PCISSLRAP: 8.1, 8.2
SCAGILE: Tasks Requiring the Help of
Security Experts 12
SCFPSSD: Verify Secure Configurations
and Use of Platform Mitigation
SCSIC: Vendor Software Delivery
Integrity Controls, Vendor Software
Development Integrity Controls
SP800181: SP-DEV-001; K0009, K0039,
K0073, K0153, K0165, K0275, K0531
22. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
19
Practices Tasks Implementation Examples References
Respond to Vulnerabilities (RV)
Identify and Confirm
Vulnerabilities on an Ongoing
Basis (RV.1): Help ensure that
vulnerabilities are identified
more quickly so they can be
remediated more quickly,
reducing the window of
opportunity for attackers.
RV.1.1: Gather information from
consumers and public sources
on potential vulnerabilities in the
software and any third-party
components that the software
uses, and investigate all credible
reports.
• Establish a vulnerability response
program, and make it easy for security
researchers to learn about your program
and report possible vulnerabilities.
• Monitor vulnerability databases, security
mailing lists, and other sources of
vulnerability reports through manual or
automated means.
• Use threat intelligence sources to better
understand how vulnerabilities in general
are being exploited.
BSA: VM.1-3, VM.3
BSIMM10: CMVM1.2, CMVM3.4
PCISSLRAP: 3.4, 4.1, 9.1
SAMM15: IM1-A
SCAGILE: Operational Security Task 5
SCTPC: 3.2.4
SP800181: K0009, K0038, K0040,
K0070, K0161, K0362; S0078
RV.1.2: Review, analyze, and/or
test the software’s code to
identify or confirm the presence
of previously undetected
vulnerabilities.
• Configure the toolchain to perform
automated code analysis and testing on
a regular basis.
• [See Review and/or Analyze Human-
Readable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.7)]
• [See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
BSA: VM.1-2
ISO27034: 7.3.6
PCISSLRAP: 3.4, 4.1
SP800181: SP-DEV-002; K0009, K0039,
K0153
[See Review and/or Analyze Human-
Readable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.7)]
[See Test Executable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.8)]
RV.1.3: Have a team and
process in place to handle the
responses to vulnerability
reports and incidents.
• Have a policy that addresses
vulnerability disclosure and remediation,
and implement the processes needed to
support that policy.
• Have a security response playbook to
handle a generic reported vulnerability, a
report of zero-days, a vulnerability being
exploited in the wild, and a major
ongoing incident involving multiple
parties.
BSA: VM.1-1, VM.2, VM.2-3
MSSDL: Practice 12
SAMM15: IM1-B, IM2-A, IM2-B
SCFPSSD: Vulnerability Response and
Disclosure
SP800160: 3.3.8
SP800181: K0041, K0042, K0151,
K0292, K0317; S0054; A0025
23. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
20
Practices Tasks Implementation Examples References
Assess, Prioritize, and
Remediate Vulnerabilities
(RV.2): Help ensure that
vulnerabilities are remediated as
quickly as necessary, reducing
the window of opportunity for
attackers.
RV.2.1: Analyze each
vulnerability to gather sufficient
information to plan its
remediation.
• Use issue tracking software (existing
software, if available) to document each
vulnerability.
• Estimate how much effort would be
required to remediate the vulnerability.
• Estimate the potential impact of
vulnerability exploitation.
• Estimate the resources needed to
weaponize the vulnerability, if that has
not already been done.
• Estimate any other relevant factors
needed to plan the remediation of the
vulnerability.
BSA: VM.2, VM.2-1, VM.2-2
PCISSLRAP: 4.2
SCAGILE: Tasks Requiring the Help of
Security Experts 10
SP80053: SA-10
SP800160: 3.3.8
SP800181: K0009, K0039, K0070,
K0161, K0165; S0078
RV.2.2: Develop and implement
a remediation plan for each
vulnerability.
• For each vulnerability, make a risk-
based decision as to whether it will be
remediated or if the risk will be
addressed through other means (e.g.,
risk acceptance, risk transference).
• For each vulnerability to be remediated,
determine how its remediation should be
prioritized.
• If a permanent mitigation for a
vulnerability is not yet available,
determine how the vulnerability can be
temporarily mitigated until the permanent
solution is available, and add that
temporary remediation to the plan.
BSA: VM.1-1, VM.2-3, VM.2-4
PCISSLRAP: 4.1, 4.2
SCAGILE: Operational Security Task 2
SCFPSSD: Fix the Vulnerability, Identify
Mitigating Factors or Workarounds
SP800181: T0163, T0229, T0264;
K0009, K0070
Analyze Vulnerabilities to
Identify Their Root Causes
(RV.3): Help reduce the
frequency of vulnerabilities in
the future.
RV.3.1: Analyze all identified
vulnerabilities to determine the
root cause of each vulnerability.
• Document the root cause of each
discovered issue.
• Document lessons learned from root
cause analysis in a knowledge base that
developers can access and search.
BSA: VM.2-1
PCISSLRAP: 4.2
SAMM15: IM3-A
SP800181: T0047, K0009, K0039,
K0070, K0343
RV.3.2: Analyze the root causes
over time to identify patterns,
such as when a particular
secure coding practice is not
being followed consistently.
• Document lessons learned from root
cause analysis in a knowledge base that
developers can access and search.
• Add mechanisms to the toolchain to
automatically detect future instances of
the root cause.
BSA: VM.2-1, PD.1-3
MSSDLPG52: Phase Two: Design
PCISSLRAP: 4.2
SP800160: 3.3.8
SP800181: T0111, K0009, K0039,
K0070, K0343
24. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
21
Practices Tasks Implementation Examples References
RV.3.3: Review the software for
other instances of the reported
problem and proactively fix them
rather than waiting for external
reports.
• [See Review and/or Analyze Human-
Readable Code to Identify
Vulnerabilities and Verify Compliance
with Security Requirements (PW.7)]
• [See Create Source Code Adhering to
Secure Coding Practices (PW.5)]
BSA: VM.2
PCISSLRAP: 4.2
SP800181: SP-DEV-001, SP-DEV-002;
K0009, K0039, K0070
RV.3.4: Review the SDLC
process, and update it as
appropriate to prevent (or
reduce the likelihood of) the root
cause recurring in updates to
this software or in new software
that is created.
• Document lessons learned from root
cause analysis in a knowledge base that
developers can access and search.
• Plan and implement changes to the
appropriate SSDF practices.
BSA: PD.1-3
BSIMM10: CMVM3.2
MSSDL: Practice 2
PCISSLRAP: 2.6, 4.2
SP800181: K0009, K0039, K0070
25. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
22
References
[1] Newhouse W, Keith S, Scribner B, Witte G (2017) National Initiative for Cybersecurity
Education (NICE) Cybersecurity Workforce Framework. (National Institute of Standards
and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-181.
https://doi.org/10.6028/NIST.SP.800-181
[2] National Institute of Standards and Technology (2018), Framework for Improving
Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standards and
Technology, Gaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.04162018
[3] Migues S, Steven J, Ware M (2019) Building Security in Maturity Model (BSIMM)
Version 10. Available at https://www.bsimm.com/download/
[4] BSA (2019) Framework for Secure Software. Available at
https://www.bsa.org/reports/bsa-framework-for-secure-software
[5] Hong Fong EK, Wheeler D, Henninger A (2016) State-of-the-Art Resources (SOAR) for
Software Vulnerability Detection, Test, and Evaluation 2016. (Institute for Defense
Analyses [IDA], Alexandria, VA), IDA Paper P-8005. Available at
https://www.ida.org/research-and-publications/publications/all/s/st/stateoftheart-
resources-soar-for-software-vulnerability-detection-test-and-evaluation-2016
[6] International Organization for Standardization/International Electrotechnical
Commission (ISO/IEC), Information technology – Security techniques – Application
security – Part 1: Overview and concepts, ISO/IEC 27034-1:2011, 2011. Available at
https://www.iso.org/standard/44378.html
[7] Microsoft (2019) Security Development Lifecycle. Available at
https://www.microsoft.com/en-us/sdl
[8] Open Web Application Security Project (2019) OWASP Application Security Verification
Standard 4.0. Available at https://github.com/OWASP/ASVS
[9] Open Web Application Security Project (2014) OWASP Testing Guide 4.0. Available at
https://www.owasp.org/images/1/19/OTGv4.pdf
[10] Payment Card Industry (PCI) Security Standards Council (2019) Secure Software
Lifecycle (Secure SLC) Requirements and Assessment Procedures Version 1.0. Available
at https://www.pcisecuritystandards.org/document_library?category=sware_sec#results
[11] Open Web Application Security Project (2017) Software Assurance Maturity Model
Version 1.5. Available at https://www.owasp.org/index.php/OWASP_SAMM_Project
[12] Software Assurance Forum for Excellence in Code (2012) Practical Security Stories and
Security Tasks for Agile Development Environments. Available at
http://www.safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf
26. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
23
[13] Software Assurance Forum for Excellence in Code (2018) Fundamental Practices for
Secure Software Development: Essential Elements of a Secure Development Lifecycle
Program, Third Edition. Available at https://safecode.org/wp-
content/uploads/2018/03/SAFECode_Fundamental_Practices_for_Secure_Software_Dev
elopment_March_2018.pdf
[14] Software Assurance Forum for Excellence in Code (2010) Software Integrity Controls:
An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain.
Available at
http://www.safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf
[15] Software Assurance Forum for Excellence in Code (2017) Managing Security Risks
Inherent in the Use of Third-Party Components. Available at
https://www.safecode.org/wp-
content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf
[16] Software Assurance Forum for Excellence in Code (2017) Tactical Threat Modeling.
Available at https://www.safecode.org/wp-
content/uploads/2017/05/SAFECode_TM_Whitepaper.pdf
[17] Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for
Federal Information Systems and Organizations. (National Institute of Standards and
Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Revision 4,
Includes updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4
[18] Ross R, McEvilley M, Oren J (2016) Systems Security Engineering: Considerations for a
Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Special
Publication (SP) 800-160, Volume 1, Includes updates as of March 21, 2018.
https://doi.org/10.6028/NIST.SP.800-160v1
27. NIST CYBERSECURITY WHITE PAPER MITIGATING THE RISK OF SOFTWARE
APRIL 23, 2020 VULNERABILITIES BY ADOPTING AN SSDF
24
Appendix A—Acronyms
BSIMM Building Security In Maturity Model
CISQ Consortium for Information & Software Quality
COTS Commercial-Off-the-Shelf
CPS Cyber-Physical System
DevOps Development and Operations
GOTS Government-Off-the-Shelf
ICS Industrial Control System
IDA Institute for Defense Analyses
IEC International Electrotechnical Commission
IoT Internet of Things
ISO International Organization for Standardization
ISPAB Information Security and Privacy Advisory Board
IT Information Technology
ITL Information Technology Laboratory
KPI Key Performance Indicator
MITA Medical Imaging & Technology Alliance
NAVSEA Naval Sea Systems Command
NICE National Initiative for Cybersecurity Education
NIST National Institute of Standards and Technology
OWASP Open Web Application Security Project
PCI Payment Card Industry
SAFECode Software Assurance Forum for Excellence in Code
SAMM Software Assurance Maturity Model
SBOM Software Bill of Materials
SDL [Microsoft] Security Development Lifecycle
SDLC Software Development Life Cycle
SEI Software Engineering Institute
SLC Software Lifecyle
SOAR State-of-the-Art Resources
SSDF Secure Software Development Framework