Secure-by-design and secure-by-default principles, use of memory-safe programming languages where possible, and secure programming practices are used as part of application development.
Define and maintain comprehensive security requirements for software development infrastructures and processes. Regularly review and update these requirements to address emerging threats, and communicate changes to all relevant personnel. This ensures that the organization’s infrastructure remains aligned with secure-by-design and secure-by-default principles throughout the software development lifecycle.
Identify security requirements for software projects by conducting a detailed review of functional requirements. Define relevant security objectives based on the desired confidentiality, integrity, or availability of the services or data provided by the software. For example, specify objectives like 'personal data should be securely stored and transmitted,' without mandating specific implementation measures upfront (e.g., 'use TLSv1.2'). Additionally, assess functionality from an attacker's perspective to identify potential misuse scenarios and determine additional protective measures. Security objectives can include specific functionality enhancements (e.g., 'Enable user identification at all times') or broader application quality goals (e.g., 'Ensure data is protected in transit'). Ensure all security requirements are specific, measurable, actionable, relevant, and time-bound (SMART). Avoid overly generic requirements (e.g., 'Protect against the OWASP Top 10') that lack actionable value or alignment with the application’s specific context. Regularly revisit and refine these requirements to address evolving threats, ensuring they remain relevant and effective throughout the development lifecycle.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-01-01-01 | Review functional requirements | Analyze the functional requirements of the project to identify areas where confidentiality, integrity, or availability could be impacted. | Preparation | Security team, Business analysts, Development leads |
| SSS-02-01-01-01-02 | Define security objectives | Based on the review, identify security objectives for the project (e.g., protect personal data in transit or ensure secure user authentication). | Preparation | Security team, Business analysts |
| SSS-02-01-01-01-03 | Perform threat modeling | Analyze the system from an attacker’s perspective to identify misuse scenarios and define additional protective security requirements. | Development | Security team, Development teams |
| SSS-02-01-01-01-04 | Write smart security requirements | Document security requirements that are Specific, Measurable, Actionable, Relevant, and Time-bound (SMART) to ensure clarity and enforceability. | Development | Security team, Business analysts, Product owners |
| SSS-02-01-01-01-05 | Validate and review requirements | Conduct a review with stakeholders to validate the requirements and ensure they align with project goals and address identified risks. | Development | Security team, Development teams, Product owners |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.1.1) OWASP SAMM: Software Assurance Maturity Model (D-SR-1-A) |
Establish secure development policies by identifying and documenting security requirements for all internally developed software. This includes risk-based architecture, design practices, and guidelines for technology stack analysis, software archiving, end-of-life notifications, and exception handling. Such practices reinforce secure-by-design principles and ensure software is built with a strong security foundation.
Standardize and integrate security requirements into development processes by systematically gathering inputs from diverse sources, including organizational policies, legislative requirements, application feedback, vulnerability metrics, and historical logs. Conduct brainstorming sessions, interviews, or workshops to identify requirements, and use structured notations that align security requirements with functional requirements for the project. Extend existing analysis documents, user stories, or other requirement specifications to include security requirements and ensure their integration into the product development lifecycle. Establish mechanisms to enforce compliance with security requirements by annotating them with priorities or integrating them into project governance. Balance these security needs against other non-functional requirements to maintain alignment with the organization's security appetite. This approach ensures that security requirements are consistently addressed, enhancing the software's resilience and alignment with secure-by-design principles.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-02-01-01 | Elicit security requirements from multiple sources | Collect security requirements systematically from policies, regulations, known application issues, and intelligence (e.g., metrics, historical logs, vulnerability databases). | Preparation | Security team, Compliance team, Development leads |
| SSS-02-01-02-01-02 | Organize stakeholder workshops and interviews | Conduct workshops, brainstorming sessions, or interviews with stakeholders to gather inputs from diverse sources, such as policies, laws, and operational needs. | Preparation | Security team, Product owners, Compliance officers |
| SSS-02-01-02-01-03 | Standardize security requirements documentation | Use a structured format (e.g., extending functional requirements documents, writing user stories) to document security requirements in a way that integrates with project workflows. | Development | Development teams, Security team, Product owners |
| SSS-02-01-02-01-04 | Prioritize and annotate security requirements | Assign priorities to security requirements and align them with the project's security appetite, balancing functional and non-functional requirements. | Development | Security team, Product managers |
| SSS-02-01-02-01-05 | Monitor and enforce compliance | Set up a process or tool to monitor and enforce compliance with security requirements during product development and testing, ensuring alignment with security objectives. | Deployment | DevOps team, QA team, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.1.2) OWASP SAMM: Software Assurance Maturity Model (D-SR-2-A) |
Communicate security requirements to third-party providers of commercial software components to ensure they meet the organization's standards. Include these requirements in contracts, establish clear selection criteria, require attestations and provenance data, and define processes for handling exceptions. This approach mitigates risks associated with integrating third-party components into secure software environments.
Strengthen supplier relationships by clearly defining and discussing security responsibilities and expectations as part of the contracting process. Specify quality requirements, such as compliance with security standards like OWASP Top 10, and assign tasks, such as conducting continuous static code analysis or independent penetration testing prior to major releases. Formalize these responsibilities in Service Level Agreements (SLAs) that include liability provisions, remediation timelines, and caps for addressing security issues. Standardize agreements with suppliers over time to streamline negotiations and ensure critical security considerations are not overlooked. While standardized agreements provide a baseline, allow for flexibility to adapt to specific supplier capabilities and project needs. This approach mitigates risks associated with third-party software components, ensuring alignment with organizational security standards and reducing vulnerabilities in the supply chain.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-03-01-01 | Define security responsibilities for suppliers | Identify and document security responsibilities for suppliers, such as quality requirements (e.g., compliance with OWASP Top 10) and specific tasks (e.g., static code analysis, penetration tests). | Preparation | Procurement team, Security team, Legal team |
| SSS-02-01-03-01-02 | Draft and establish supplier agreements | Develop a Service Level Agreement (SLA) or contract that outlines supplier responsibilities, tasks, quality requirements, liabilities, and penalties for non-compliance. | Preparation | Procurement team, Legal team, Security team |
| SSS-02-01-03-01-03 | Communicate responsibilities and expectations | Conduct discussions with suppliers to clarify security expectations, responsibilities, and deliverables. Ensure mutual understanding and agreement. | Development | Procurement team, Supplier representatives |
| SSS-02-01-03-01-04 | Standardize supplier agreements | Create a template for supplier agreements to streamline negotiations while allowing for case-specific adjustments. Regularly review and update this template as needed. | Development | Legal team, Procurement team, Security team |
| SSS-02-01-03-01-05 | Monitor supplier compliance | Set up processes to verify supplier compliance with agreed security responsibilities, such as regular audits, progress reports, or integration with your development workflows. | Post-deployment | Security team, Procurement team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.1.3) OWASP SAMM: Software Assurance Maturity Model (D-SR-2-B) |
Define and periodically review roles and responsibilities for all SDLC team members, ensuring they incorporate security-related tasks. Designate code ownership, promote cross-functional communication, and adapt roles to support secure development practices, fostering accountability and a strong security culture within the development process.
Establish a Security Champion program within each software development team to enhance application security and foster collaboration between Information Security and development teams. A Security Champion, selected from roles such as developer, tester, or product manager, dedicates a portion of their time to Information Security activities and acts as a liaison between teams. These champions receive specialized training to become subject-matter experts in software security and participate in regular security briefings to stay updated on best practices and emerging threats. The Security Champion's responsibilities include identifying, prioritizing, and addressing security and compliance-related defects, as well as assisting in risk assessments, threat assessments, and architectural reviews. They play a critical role in strengthening the application's resilience by identifying opportunities to reduce attack surfaces and improve design. Security Champions also conduct periodic reviews of security-related issues, ensuring all team members are aware of existing vulnerabilities, ongoing remediation efforts, and future plans. By facilitating brainstorming sessions and promoting cross-functional communication, they help the team collaboratively address complex security challenges, building a robust security culture across the organization.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-04-01-01 | Define the role and responsibilities of security champions | Clearly outline the responsibilities of Security Champions, including liaising with the Information Security team, reviewing security defects, and participating in risk and threat assessments. | Preparation | Security team, Development leads, Product managers |
| SSS-02-01-04-01-02 | Select and assign security champions | Identify and assign a Security Champion in each software development team. Select individuals with a strong understanding of the project and an interest in security practices. | Development | Development leads, Security team, HR team |
| SSS-02-01-04-01-03 | Provide specialized training for security champions | Offer additional training programs to help Security Champions become subject-matter experts in application security, compliance, and threat modeling. | Development | Security team, External training providers |
| SSS-02-01-04-01-04 | Establish a regular communication framework | Organize periodic meetings, briefings, and collaborative sessions for Security Champions to share updates, insights, and solutions to common security challenges. | Development | Security team, Development teams |
| SSS-02-01-04-01-05 | Empower champions in security processes | Include Security Champions in critical security processes, such as architectural reviews, risk assessments, and threat modeling, to ensure their involvement in key decision-making. | Deployment | Development teams, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.2.1) OWASP SAMM: Software Assurance Maturity Model (G-EG-1-B) |
To establish a security community, the organization must foster collaboration and communication among employees involved in software security. Security must be treated as everyone's responsibility, not just the Information Security team's. This involves creating platforms for knowledge sharing, forming communities around roles and responsibilities, and encouraging engagement. Recognition programs promote active participation and identify potential Security Champions. The initiative supports application security improvement and enhances the organization's SDLC maturity by regularly disseminating updates, tools, and training.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-04-02-01 | Deploy Communication and Knowledge-Sharing Platforms | Implement tools (e.g., forums, Slack, SharePoint) to enable developers and engineers to share information, discuss challenges, and access a knowledge base of previously addressed issues, building communities around technologies, tools, and programming languages. | Preparation | Security Teams |
| SSS-02-01-04-02-02 | Form communities around roles and responsibilities | Create groups based on roles (e.g., developers, testers, engineers) and responsibilities to facilitate cross-team collaboration. Encourage communication across business units, allowing members to share expertise and learn from each other. | Development | Team Leaders |
| SSS-02-01-04-02-03 | Promote participation and recognize contributions | Establish a recognition program to reward employees who contribute the most to the community, promoting them as thought leaders. Use management recognition to encourage participation and foster a culture of knowledge sharing and collaboration. | Deployment | Management Teams |
| SSS-02-01-04-02-04 | Review and maintain the information portal | Have the Secure Software Center of Excellence and Application Security teams regularly review the portal for new insights, identify trends, and provide developers with updates on standards, tools, and training resources to improve SDLC maturity and application security. | Post-deployment | Secure Software Center of Excellence |
| SSS-02-01-04-02-05 | Identify and empower security champions | Use community engagement metrics and contributions to identify future Security Champions. Provide them with resources, responsibilities, and training to further strengthen their role in advancing application security and assisting the development community. | Post-deployment | Application Security Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.2.1) OWASP SAMM: Software Assurance Maturity Model (G-EG-3-B) |
To enhance application security, provide comprehensive security awareness training to all personnel involved in software development, including management, developers, testers, and auditors. This training should emphasize understanding application security threats, risks, best practices, and secure design principles like Least Privilege, Defense-in-Depth, and Fail Secure. Cover key organizational standards and high-level overviews of vulnerabilities, such as the OWASP Top 10. Training can be developed internally or sourced externally, with a preference for in-person sessions to encourage team discussions. Computer-Based Training (CBT) is an alternative. Use innovative methods like gamification to keep the content engaging and effective. The training must be mandatory and include an auditable sign-off to demonstrate compliance. This initiative ensures that all stakeholders are equipped with the knowledge to mitigate security risks, align with organizational security policies, and contribute to the development of secure software.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-04-03-01 | Develop or procure security awareness training | Create or procure training materials tailored to the roles involved in software development, covering secure design principles, organizational standards, and the OWASP Top 10 vulnerabilities. Ensure the content is accessible to both technical and non-technical audiences. | Preparation | Training Teams |
| SSS-02-01-04-03-02 | Deliver training to all relevant stakeholders | Conduct mandatory security awareness training for all employees and contractors involved in the software lifecycle. Deliver training in person for team discussions where possible, or use Computer-Based Training (CBT) as an alternative. | Development | Training Teams |
| SSS-02-01-04-03-03 | Incorporate innovative training methods | Utilize methods such as gamification to engage participants, improve retention of key concepts, and combat desensitization. Tailor the delivery style to maximize effectiveness for diverse learning preferences. | Deployment | Training Teams |
| SSS-02-01-04-03-04 | Track and audit training compliance | Implement a system for auditable sign-offs to ensure all stakeholders complete the training and demonstrate compliance. Use these records for reporting and continuous improvement of training programs. | Post-deployment | Compliance Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.2.1) OWASP SAMM: Software Assurance Maturity Model (G-EG-1-A) |
Provide role-specific, secure development training, including regular proficiency assessments and updates to training as needed. Define desired outcomes for each role, plan training accordingly, and measure effectiveness to continuously improve skillsets, ensuring personnel are equipped to support secure development practices.
Design and deliver customized security training tailored to the organization's roles and technologies, ensuring all software development personnel are equipped with the necessary skills to maintain secure development practices. Training should address the unique responsibilities and technical requirements of the roles such as "Product Managers: Focus on SAMM business functions, security practices, threat modeling, and defect tracking to align business processes with application security", "Developers: Emphasize secure coding standards, OWASP Top 10 vulnerabilities, and framework-specific weaknesses (e.g., mobile). Include remediation strategies to address common security issues effectively", "Testers: Provide training on testing tools, best practices, and techniques for identifying and documenting security defects", "Security Auditors: Focus on SDLC application security mechanisms and processes for submitting security defects for remediation", and "Security Champions: Include advanced training on threat modeling, secure design, and integrating security tools into development workflows". Training should include interactive demonstrations of vulnerability exploitation using weakened applications (e.g., WebGoat or Juice Shop), case studies of previous penetration test results, and strategies for implementing remediation. Involve subject-matter experts and penetration testers in developing and delivering content. All training programs should be mandatory for employees and contractors involved in software development and include measurable assessments to verify understanding. Update training annually to reflect changes in organizational practices, technologies, and emerging threats. Collect feedback from participants to continuously improve the training's relevance and effectiveness.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-05-01-01 | Identify role-specific training needs | Analyze the responsibilities of different roles (e.g., product managers, developers, testers, security auditors, and Security Champions) and define their specific security training needs. | Preparation | Security team, HR team, Development leads |
| SSS-02-01-05-01-02 | Develop and customize training content | Create or procure training content tailored to the technologies, frameworks, and security needs of each role. Include demonstrations of vulnerabilities (e.g., using WebGoat or Juice Shop) and remediation examples. | Development | Security team, Subject-matter experts (SMEs) |
| SSS-02-01-05-01-03 | Deliver interactive and mandatory training | Conduct instructor-led or computer-based training sessions. Include hands-on vulnerability exploitation exercises, real-world examples, and role-specific best practices. | Development | Security team, External trainers, Development teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.2.2) OWASP SAMM: Software Assurance Maturity Model (G-EG-2-A) |
Secure commitment from upper management for secure development, and communicate this support to all development-related personnel. Appoint a leader to oversee the process, raise awareness of insecure development risks, and educate staff on the significance of security-focused practices within the organization.
Develop a comprehensive security strategy that aligns with the organization's business priorities, risk tolerance, and resource constraints. This strategy should include a 1-3 year roadmap addressing application security objectives and detailing tactical and strategic initiatives. The roadmap must align with the organization’s business drivers and threats, balancing financial costs, procedural adjustments, and cultural changes without overburdening teams or resources. Set clear milestones to monitor progress, with frequent assessments to allow for timely adjustments. To ensure success, secure buy-in from stakeholders, including upper management, application security teams, and development teams, emphasizing the importance of their active participation. Publish the strategic plan to ensure transparency and accessibility for all relevant personnel involved in its implementation. This approach raises awareness, fosters collaboration, and embeds security-focused practices across the organization, guided by visible leadership and structured objectives.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-06-01-01 | Assess assets, threats, and risk tolerance | Use frameworks like NIST or ISO 27001 to evaluate assets and risks, identifying critical systems and applications to prioritize. | Preparation | Security team, Risk management team, Development leads |
| SSS-02-01-06-01-02 | Develop a security strategic plan and roadmap | Create a 1 to 3-year strategic plan that aligns with business priorities, outlining tactical and strategic initiatives. Include specific initiatives like implementing static code analysis tools, conducting quarterly penetration tests, or creating secure coding guidelines. | Preparation | Security team, Business leaders, Finance team |
| SSS-02-01-06-01-03 | Balance initiatives across financial, process, and cultural changes | Balance budget allocations for new security tools with process changes like DevSecOps integration and cultural initiatives like security training programs. | Development | Security team, HR team, Development teams |
| SSS-02-01-06-01-04 | Obtain stakeholder buy-in and publish the plan | Present the plan in an executive meeting, emphasize alignment with business goals, and share a simplified version with development teams for transparency. | Development | Upper management, Security team, Development teams |
| SSS-02-01-06-01-05 | Track milestones and adjust the roadmap | Monitor progress against defined milestones to measure success. Adjust the roadmap based on feedback and changing business or risk priorities. | Post-deployment | Security team, Project managers, Development teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PO.2.3) OWASP SAMM: Software Assurance Maturity Model (G-SM-2-A) |
Maintain comprehensive records of security requirements, risks, and design decisions throughout the software's lifecycle. Track responses to each risk, including mitigations and justifications for exceptions, and periodically review these records to make necessary updates, ensuring an ongoing focus on security management and risk mitigation.
Conduct regular application risk assessments to evaluate the potential business impact of attacks, focusing on breaches of confidentiality, integrity, and availability. Use a straightforward methodology, such as a structured set of 5-10 questions, to identify key application characteristics, including whether the application processes sensitive financial or privacy-related data or if it is internet-facing. Based on these findings, create a risk profile for each application and classify them using a simple qualitative scheme (e.g., high/medium/low risk). Use these classifications to prioritize security efforts and compare risks across applications. Mature organizations with risk-driven frameworks may employ more advanced quantitative methods but should leverage existing effective schemes where applicable rather than creating new ones unnecessarily. This structured assessment process ensures consistent evaluation and documentation of application risks, enabling effective risk mitigation and informed decision-making throughout the software lifecycle.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-07-01-01 | Standardized Application Risk Evaluation Questions | Develop a set of 5-10 standardized questions to evaluate application risk, focusing on confidentiality, integrity, and availability (CIA), and key characteristics (e.g., financial data, privacy). | Preparation | Security team, Risk management team, Business analysts |
| SSS-02-01-07-01-02 | Conduct application risk assessments | Use the defined criteria to assess each application and understand its risk profile. Evaluate factors such as whether the application is internet-facing or processes sensitive data. | Development | Development teams, Security team |
| SSS-02-01-07-01-03 | Classify applications by risk level | Assign qualitative risk levels (e.g., high, medium, low) to applications based on the assessment results, ensuring consistent and comparable evaluations. | Development | Security team, Risk management team |
| SSS-02-01-07-01-04 | Document and share risk profiles | Maintain a centralized repository of application risk profiles, making them accessible to relevant stakeholders for prioritizing security efforts and tracking over time. | Deployment | Security team, Development leads, Compliance team |
| SSS-02-01-07-01-05 | Periodically reassess application risk | Conduct regular reviews or reassessments following major application changes, such as new features, integrations, or changes in the threat landscape | Post-deployment | Security team, Risk management team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.1.2) OWASP SAMM: Software Assurance Maturity Model (D-TA-1-A) |
Establish a comprehensive inventory of application risk profiles to evaluate and prioritize security assurance activities across the organization. Implement an extensive, standardized evaluation framework that assesses risks related to information security (confidentiality, integrity, and availability of data), privacy concerns, and the interdependencies between applications (e.g., potential modifications to data categorized as read-only by other systems). This assessment should include all applications, including existing and legacy systems. Utilize business impact analysis to quantify and classify application risks, acknowledging that simple qualitative schemes (e.g., high/medium/low) may not sufficiently capture enterprise-wide complexities. Instead, adopt a more robust classification approach that enables consistent comparisons and prioritization across applications. Leverage these risk profiles to create a centralized inventory managed by Security Officers, providing accountability and transparency. This inventory equips Product Owners, Managers, and other organizational stakeholders with a clear, unified understanding of application risk levels, enabling informed decision-making and prioritization of security-related activities.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-07-02-01 | Develop a comprehensive risk evaluation framework | ncorporate frameworks like NIST SP 800-30 or FAIR to evaluate risks thoroughly. Include questions on privacy implications and application interdependencies. | Preparation | Security team, Risk management team, Business analysts |
| SSS-02-01-07-02-02 | Conduct risk assessments across all applications | Evaluate all applications (existing, legacy, and new) to quantify and classify their risk levels using business impact analysis, covering security, privacy, and dependencies. | Development | Security team, Development leads, Compliance team |
| SSS-02-01-07-02-03 | Quantify and classify risks with advanced metrics | Leverage detailed metrics (e.g., financial impact, compliance penalties) to classify application risks on an enterprise-wide level, enabling more granular prioritization. | Development | Risk management team, Security team |
| SSS-02-01-07-02-04 | Build a centralized risk profile inventory | Consolidate risk profiles into a centralized inventory tool, making them accessible to stakeholders such as Security Officers to prioritize security activities. | Deployment | Security team, Product managers, IT operations |
| SSS-02-01-07-02-05 | Review and update the inventory regularly | Establish a schedule to reassess and update the risk profiles of applications to reflect changes in business operations, application use, and threat landscapes. | Post-deployment | Security team, Risk management team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.1.2) OWASP SAMM: Software Assurance Maturity Model (D-TA-2-A) |
Adopt a standardized threat modeling methodology aligned with application risk levels to systematically identify, prioritize, and address potential security threats across the organization. Train architects, security champions, and other stakeholders in practical threat modeling techniques, using detailed playbooks, templates, and organization-specific examples. Ensure the methodology includes key components such as system diagramming, threat identification, design flaw mitigation strategies, and validation of threat model artifacts. Leverage frameworks like STRIDE or organization-specific threat checklists to uncover vulnerabilities and rank design flaws by risk level. Implement mitigating controls for identified threats and ensure stakeholders have the tools and knowledge needed to address these risks effectively. Define triggers for updating threat models, such as technological changes or new deployment environments, to maintain their relevance. Integrate the outputs of threat modeling into defect management processes for effective follow-up. Utilize application team tools to document and manage threat modeling artifacts, ensuring they are accessible, actionable, and updated as necessary. This standardized approach scales threat modeling across the organization, reinforcing proactive risk management and enhancing security posture.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-07-03-01 | Adopt a standardized threat modeling methodology | Select and formalize a threat modeling approach (e.g., STRIDE, LINDDUN) tailored to organizational needs, aligned with application risk levels, and compatible with existing processes. | Preparation | Security team, Architects, Risk management team |
| SSS-02-01-07-03-02 | Train stakeholders in threat modeling | Provide hands-on training for architects, Security Champions, and other stakeholders, focusing on diagramming, threat identification, design flaw mitigation, and validation. | Development | Security team, External trainers, Development teams |
| SSS-02-01-07-03-03 | Create threat modeling playbooks and templates | Develop standardized playbooks, templates, and organization-specific examples to make the threat modeling process clear, repeatable, and scalable across teams. | Development | Security team, Architects |
| SSS-02-01-07-03-04 | Integrate threat models with defect management | Ensure the output of threat modeling feeds directly into the defect management process, enabling seamless follow-up on identified risks and mitigations. | Development | Security team, Development leads |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.1.2) OWASP SAMM: Software Assurance Maturity Model (D-TA-2-B) |
Acquire and manage secure third-party software components, including libraries and frameworks, by reviewing and evaluating them based on intended use, verifying secure configurations, maintaining an approved list, and implementing update processes. This ensures that all components meet security standards and align with the organization's secure development goals.
Maintain a whitelist of approved dependencies and versions to enforce rigorous control over third-party software components. Configure the build process to automatically fail if unapproved dependencies are detected, with a defined sign-off procedure for handling justified exceptions. Perform security verification activities for approved dependencies, using methodologies such as Static Application Security Testing (SAST) and analyzing transitive dependencies to ensure alignment with the organization’s security standards. Extend these checks to detect potential vulnerabilities such as backdoors, malicious code, or ‘easter eggs’ in the dependencies. Collaborate with dependency authors by establishing vulnerability disclosure protocols, including Service Level Agreements (SLAs) for addressing identified issues. Where SLAs are not feasible, such as in open-source environments, anticipate probable vulnerabilities and implement compensating controls promptly to mitigate associated risks. Conduct regression testing to validate fixes for identified issues and track their resolution status within a defect tracking system. Integrate this tracking system with the build pipeline to automatically halt builds if dependencies with unresolved issues surpass a defined criticality threshold. This comprehensive approach ensures that all dependencies meet the organization’s security objectives and mitigate risks associated with third-party components effectively.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-08-01-01 | Maintain and enforce a whitelist of dependencies | Create and regularly update a whitelist of approved dependencies and their versions. Ensure the build process fails when unapproved dependencies are detected. | Development | DevOps team, Security team |
| SSS-02-01-08-01-02 | Perform security verification on dependencies | Conduct security testing (e.g., SAST, transitive dependency analysis) on approved dependencies to identify vulnerabilities, backdoors, or easter eggs. | Development | Security team, Development teams |
| SSS-02-01-08-01-03 | Establish vulnerability disclosure processes | Work with dependency authors to set up SLAs for fixing vulnerabilities. If SLAs cannot be enforced (e.g., open-source), prepare compensating controls to mitigate risks. | Deployment | Security team, Procurement team |
| SSS-02-01-08-01-04 | Implement build pipeline integration for dependency checks | Integrate dependency vulnerability scanning tools into the CI/CD pipeline. Automatically fail builds if vulnerabilities above a criticality threshold are detected. | Deployment | DevOps team, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.4.1) OWASP SAMM: Software Assurance Maturity Model (I-SB-3-B) |
Develop and maintain in-house software components that meet organizational security standards when third-party options are insufficient. Follow SDLC processes, secure configurations, and update protocols to address internal software development needs securely.
To enhance software security, organizations should maintain an accurate record of all application dependencies, referred to as a Bill of Materials (BOM). This includes both server-side and client-side dependencies. Records should include detailed information about each dependency, such as where it is used, its version, license, source, and maintenance status. Use tools and methods like package managers or IDEs to list dependencies. Regularly analyze these records to identify vulnerabilities in dependencies and take corrective actions, such as updating or replacing outdated or insecure components. This process ensures better visibility, traceability, and security for application components.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-09-01-01 | Create a bill of materials (BOM) | Identify and document all dependencies used by the application, including server-side and client-side components. Use tools like package managers, configuration files, or IDEs to generate a comprehensive BOM for the production environment. | Development | Development Teams |
| SSS-02-01-09-01-02 | Gather detailed dependency information | Collect detailed metadata for each dependency, including where it is used, its version, license type, source repository, and maintenance status. Ensure the records are complete and up-to-date for accurate analysis. | Development | DevOps Teams |
| SSS-02-01-09-01-03 | Analyze dependencies for vulnerabilities | Regularly review the BOM to identify dependencies with known vulnerabilities. Use tools like vulnerability scanners or CVE databases to discover potential risks and prioritize actions based on severity and impact. | Deployment | Security Teams |
| SSS-02-01-09-01-04 | Update or replace vulnerable dependencies | Address vulnerabilities by updating to secure versions of dependencies or replacing them with alternatives. Ensure compatibility and security before applying changes to the production environment. | Post-deployment | DevOps Teams |
| SSS-02-01-09-01-05 | Automate dependency management | Implement automated tools for tracking, analyzing, and managing dependencies. This includes setting up alerts for new vulnerabilities and integrating automated checks into the CI/CD pipeline to enforce the use of secure dependencies. | Post-deployment | Automation Engineers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.4.2) OWASP SAMM: Software Assurance Maturity Model (I-SB-1-B) |
Ensure that all in-house software producers follow a consistent build process to establish predictable and verifiable artifacts. This approach enables stakeholders, including verifiers, to form expectations about what constitutes a 'correct' build, thus enhancing trust in the development lifecycle. For verification purposes, producers may provide explicit metadata about the build process. This metadata should include information such as the artifact's source repository, build parameters, and security configurations. In cases where explicit metadata is not shared, verifiers may rely on implicit trust mechanisms, such as 'trust on first use,' to validate the artifact. When distributing artifacts via a package ecosystem that mandates explicit metadata in configuration files, producers must ensure these files are completed, accurate, and kept up to date. This practice not only ensures compliance with ecosystem requirements but also strengthens traceability and confidence in the integrity of internally developed software components.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-09-02-01 | Standardize the build process | Define and document a standardized build process that includes consistent build tools, parameters, and configurations for all artifacts. | Preparation | Build engineers, Development leads |
| SSS-02-01-09-02-02 | Generate and maintain build metadata | Produce metadata for every build, including details about the source repository, build parameters, and configurations. Ensure metadata is complete and up-to-date. | Development | Build engineers, Security team |
| SSS-02-01-09-02-03 | Enable metadata verification | Ensure the build metadata is accessible to verifiers. Use explicit metadata (e.g., configuration files) for ecosystems that require it, or trust-on-first-use (TOFU) when appropriate. | Deployment | Build engineers, DevOps team |
| SSS-02-01-09-02-04 | Integrate metadata updates into ci/cd | Automate the generation and updating of build metadata within the CI/CD pipeline to ensure consistency across all builds. | Deployment | DevOps team, Build engineer |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.4.2) SLSA Supply-chain Levels for Software Artifacts (Level 2,3. Producer-Follow a consistent build process) |
Verify compliance of third-party software components with organizational security requirements throughout their lifecycle. Regularly monitor for known vulnerabilities, use automated detection tools, plan for end-of-life scenarios, and conduct integrity checks. This practice minimizes risks associated with third-party software and ensures ongoing compliance with secure-by-design principles.
Evaluate and maintain an approved list of application dependencies to ensure compliance with organizational security requirements. Establish a central repository for approved dependencies to standardize and secure software builds across teams and projects. Regularly review dependencies to confirm that they are correctly licensed, no significant vulnerabilities impacting the application are present, dependencies are actively supported and maintained by their creators. . The latest or a secure, stable version is being used, and each dependency is included based on a valid business or technical need. Utilize automated tools to scan for vulnerabilities in dependencies, assign identified issues to the appropriate development teams, and track remediation efforts. Address non-conformities promptly by treating them as defects. Additionally, incorporate plans for end-of-life scenarios to manage and replace deprecated dependencies proactively. These measures help maintain robust security throughout the dependency lifecycle and align with secure-by-design principles.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-10-01-01 | Define evaluation criteria for dependencies | Establish clear criteria for evaluating dependencies, including licensing, vulnerability status, support, versioning, and business justification for inclusion. | Preparation | Security team, Development leads, Legal team |
| SSS-02-01-10-01-02 | Create and maintain a central repository | Set up a central repository (e.g., Nexus, Artifactory) containing approved and pre-validated dependencies, ensuring all projects pull from this controlled source. | Development | DevOps team, Security team |
| SSS-02-01-10-01-03 | Automate dependency scanning and monitoring | Integrate tools like Snyk, Dependabot, or OWASP Dependency-Check into the CI/CD pipeline to detect vulnerable, outdated, or non-conforming dependencies. | Development | DevOps team, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.4.4) OWASP SAMM: Software Assurance Maturity Model (I-SB-2-B) |
Conduct proactive security analysis of open-source software (OSS) to identify potential zero-day vulnerabilities, backdoors, and other security risks. Utilize advanced automated tools and manual inspection to thoroughly examine OSS dependencies used in your environment. For any vulnerabilities or risks discovered, responsibly disclose them to the upstream OSS project or maintainers to support timely remediation. Establish clear guidelines and processes for disclosure, ensuring alignment with responsible disclosure practices and fostering collaboration with the OSS community. By identifying and addressing vulnerabilities proactively, the organization strengthens its security posture while contributing to the wider ecosystem's security improvements.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-10-02-01 | Conduct proactive security scanning | Use tools like Semgrep, Trivy, or Clair to perform deep scans of OSS libraries for hidden vulnerabilities or malicious code. | Development | Security team, DevOps team |
| SSS-02-01-10-02-01 | Perform manual code review for critical oss | Assign security analysts to review OSS code critical to the application (e.g., cryptography libraries or authentication modules). | Development | Security team, Development leads |
| SSS-02-01-10-02-01 | Develop responsible disclosure processes | Use platforms like HackerOne or email directly to OSS project maintainers to report vulnerabilities securely. | Deployment | Security team, OSS contributors |
| SSS-02-01-10-02-01 | Track and monitor oss vulnerabilities | Use defect tracking tools like JIRA to log vulnerabilities and track their status until resolved or mitigated. | Post-deployment | Security team, Development leads |
| SSS-02-01-10-02-01 | Implement temporary mitigations for identified vulnerabilities | Apply a local patch or restrict functionality if a zero-day vulnerability is found in a dependency critical to the application. | Post-deployment | Development teams, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.4.4) S2C2F: Secure Supply Chain Consumption Framework (SCA-5) |
Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.
To ensure secure software development, implement robust coding practices that minimize vulnerabilities and maintain code quality. These include input/output validation, avoiding unsafe functions, and implementing proper error handling. Leverage tools and environments that encourage secure coding through automation, such as linters, formatters, and just-in-time training features. When automated methods are insufficient, follow manual compliance procedures. Regularly check for vulnerabilities specific to development languages and environments, and require developers to review their code alongside formal code reviews by others.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-01-11-01-01 | Validate and secure inputs/outputs | Implement robust input validation to prevent injection attacks and ensure all outputs are properly encoded to mitigate vulnerabilities such as cross-site scripting (XSS). | Development | Developers |
| SSS-02-01-11-01-02 | Utilize secure coding tools and standards | Use tools like linters and formatters to enforce coding standards, and configure development environments to provide just-in-time secure coding training. Ensure consistent application of secure coding principles. | Development | DevOps Teams |
| SSS-02-01-11-01-03 | Implement error handling and logging | Detect errors and handle them gracefully to avoid exposing sensitive information. Incorporate logging and tracing capabilities to track issues and support debugging without compromising application security. | Development | Developers |
| SSS-02-01-11-01-04 | Perform manual and automated code reviews | Use automated tools to detect common vulnerabilities and require developers to conduct self-reviews of their human-readable code. Complement this with peer or tool-assisted code reviews to ensure comprehensive compliance with secure coding standards. | Deployment | Quality Assurance Teams |
| SSS-02-01-11-01-05 | Check for language-specific vulnerabilities | Regularly analyze the source code for vulnerabilities specific to the programming languages and development environments in use. Update practices as new threats emerge and ensure all findings are addressed before deployment. | Post-deployment | Security Analysts |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-0401) NIST Secure Software Development Framework (PW.5.1) SSDF (PW.5.1: Follow all secure coding practices- Example) |