SecDevOps practices are used for application development.
Define the necessary tools and tool types in each toolchain to mitigate risks effectively and integrate them seamlessly. This includes categorizing essential tools, identifying security-specific tools, standardizing data formats for tool interaction, evaluating digital signing capabilities for auditability, and leveraging automated technologies to manage and orchestrate the toolchain. These actions ensure that the toolchain is secure, consistent, and auditable within DevOps practices.
Evaluate and identify critical technologies, frameworks, tools, and integrations utilized across applications to ensure security and scalability. Collaborate with architects to analyze the development and operational environments, as well as related artifacts, assessing them for security quality. Recognize that while new technologies may improve efficiency or scalability, they can also introduce risks. Implement processes to manage these risks effectively, including documenting findings and prioritizing mitigation actions. Utilize a structured approach to categorize and integrate tools into the toolchain, ensuring they align with organizational security policies and support secure-by-design principles.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-01-01-01 | Inventory key tools and technologies | Identify tools such as React for frontend development, Docker for containerization, and Jenkins for CI/CD. | Preparation | Architects, Development teams, Security team |
| SSS-02-02-01-01-02 | Assess development and operating environments | Review how Kubernetes is configured for application scaling and its implications on security. | Development | Architects, DevOps team |
| SSS-02-02-01-01-03 | Evaluate security posture of technologies | Use tools like Dependency-Check to assess libraries, and CIS Benchmarks to evaluate cloud infrastructure configurations. | Development | Security team, Architects |
| SSS-02-02-01-01-04 | Report and manage identified risks | Report risks such as using an unsupported version of a framework in the defect tracking system and assign them to the team. | Deployment | Security team, Development leads |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.3.1) OWASP SAMM: Software Assurance Maturity Model (D-SA-1-B) |
Establish and maintain a repository of preferred technologies, frameworks, and tools, focusing on those widely used across the organization’s software projects. Ensure this repository includes high-level technologies vetted for security, reliability, and compatibility with organizational goals. When curating this list, assess each tool's incident history, ability to respond to vulnerabilities, functionality relevance, ease of use, and internal familiarity. Engage senior developers, architects, managers, and security auditors to collaboratively identify and validate these recommendations. Share the list across development teams as a trusted source of default tools and perform periodic reviews to address emerging security and operational needs, ensuring continuous alignment with best practices.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-01-02-01 | Identify commonly used tools and technologies | Compile a list of common tools like Spring Boot for backend development and React for frontend. | Preparation | Architects, Development leads, Security auditors |
| SSS-02-02-01-02-02 | Evaluate tools against selection criteria | Evaluate Django for security patches and community support compared to similar frameworks. | Preparation | Senior developers, Architects, Security team |
| SSS-02-02-01-02-03 | Create a recommended tools and technologies list | Publish a preferred list including tools like GitHub Actions for CI/CD and PostgreSQL for databases. | Development | Architects, Development managers, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.3.1) OWASP SAMM: Software Assurance Maturity Model (D-SA-2-B) |
Ensure strict separation and protection across all environments involved in software development. For example, enforce multi-factor authentication, conditional access, and network segmentation and restrict connections and monitor continuously, with minimal direct human access and reduced use of production software in non-production settings; Maintain a zero-trust architecture, logging and auditing all operations, access attempts, and security controls; Proactively monitor for vulnerabilities is necessary to uphold robust environmental segregation and security.
Protect production secrets to prevent developers from accessing secrets or credentials for production environments. Implement mechanisms to safeguard these secrets, such as limiting access to authorized personnel using a separation of duties principle and encrypting production secrets stored in configuration files before deployment. Prevent leakage across environments to ensure that production secrets are never used in development or testing environments, as these typically have lower security standards. Avoid storing unprotected secrets in code repositories. Adopt secure storage practices- use encryption-at-rest for all sensitive credentials and secrets associated with production systems. Leverage dedicated tools for secure key and secrets management. Enforce access controls and implement rigorous key management protocols to ensure that only personnel authorized for production deployments can access sensitive data. These practices enhance environmental security, reduce risk exposure, and uphold the integrity of application configurations and credentials.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-02-01-01 | Implement separation of duties for secret management | Ensure that only authorized personnel have access to add production secrets to configuration files upon deployment. Follow the separation of duty principle, where developers do not have access to production secrets, limiting access to those responsible for production deployments. | Deployment | Security teams, DevOps teams |
| SSS-02-02-02-01-02 | Encrypt secrets in configuration files | Encrypt all production secrets in configuration files to prevent unauthorized access. Do not store plaintext secrets in configuration files, especially in development or testing environments, as these environments often have lower security standards. | Development | Security teams, IT Operations |
| SSS-02-02-02-01-03 | Avoid storing secrets in code repositories | Prohibit the storage of unprotected secrets in code repositories to prevent potential exposure. Use a dedicated tool for managing secrets securely, ensuring that sensitive credentials and secrets are encrypted and not accessible through version control systems. | Development | DevOps teams, Security teams |
| SSS-02-02-02-01-04 | Secure key management for access control | Implement encryption-at-rest for all sensitive credentials in production systems and handle key management securely. Restrict access to keys to only those personnel responsible for production deployments, maintaining strict access control to protect sensitive data. | Post-deployment | Security teams, Compliance officers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.5.1) OWASP SAMM: Software Assurance Maturity Model (I-SD-1-B) |
All build processes must be executed on isolated, hosted build platforms operating on shared or dedicated infrastructure rather than individual workstations. This requirement enforces strict environmental segregation, aligning with the principles of zero-trust architecture and robust environmental protection. Examples of hosted build platforms include GitHub Actions, Google Cloud Build, and Travis CI.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-02-02-01 | Select a hosted build platform | Use a hosted build platform, such as GitHub Actions or Google Cloud Build, on shared or dedicated cloud infrastructure instead of individual workstations. This ensures isolation and controlled access. | Preparation | Security Team, DevOps Team, Project Manager |
| SSS-02-02-02-02-02 | Isolate hosted environments | Restrict builds from running on local development workstations by enforcing policies that only allow builds to start on the hosted platform. Regularly monitor build requests to confirm they originate from approved environments. | Development | Security Team, DevOps Team |
| SSS-02-02-02-02-03 | Use digital signatures | Attach a digital signature to each build to certify its origin and prevent tampering, linking it to the hosted infrastructure. Use a secure key management system within the platform to handle digital signatures. | Development | Security Team, DevOps Team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.5.1) SLSA Supply-chain Levels for Software Artifacts (Level 2,3. Build platform-Isolation strength-Hosted) |
Build platforms must enforce isolation to ensure that runs cannot influence each other, even within the same project. Isolation safeguards include preventing builds from accessing platform secrets, such as provenance signing keys, ensuring the integrity of the build provenance, ensuring builds that overlap in time cannot interact preventing issues such as memory manipulation across builds, provisioning ephemeral environments for each build preventing persistent influences between consecutive builds, mitigating risks of "cache poisoning" by ensuring outputs remain consistent regardless of cache usage, and restricting remote influence or interactions unless they are explicitly captured and audited as external parameters. These measures ensure robust separation and maintain the security and integrity of all development and operational environments.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-02-03-01 | Ensure Secret Isolation | Configure the build platform to prevent builds from accessing platform secrets, such as provenance signing keys, to maintain the authenticity of the build provenance. This step ensures that secrets are fully isolated and inaccessible to build processes. | Development | Security Teams, Build Platform Engineers |
| SSS-02-02-02-03-02 | Enforce ephemeral build environments | Provision an ephemeral, isolated environment for each build to prevent one build from persisting data or influencing subsequent builds. This guarantees that each build runs independently and does not retain any state after completion. | Deployment | DevOps Teams, IT Operations |
| SSS-02-02-02-03-03 | Prevent concurrent build interference | Implement controls to ensure that builds running concurrently cannot affect one another. For example, prevent any shared memory access or other forms of cross-build influence to ensure each build is fully isolated, even if they overlap in time. | Development | Infrastructure Teams, Security Engineers |
| SSS-02-02-02-03-04 | Safeguard against cache poisoning | Configure the build platform to prevent one build from injecting false entries into a shared build cache used by another build, ensuring consistent build outputs regardless of cache usage. This step protects against "cache poisoning" attacks. | Post-deployment | DevOps Teams, Security Analysts |
| SSS-02-02-02-03-05 | Restrict remote influence | Ensure the build platform does not open services that allow remote influence on the build environment unless explicitly defined as external parameters in the provenance. This step prevents unauthorized remote access or control over the build process. | Development | Security Teams, Build Platform Engineers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.5.1) SLSA Supply-chain Levels for Software Artifacts (Level 3. Build platform-Isolation strength-Isolated) |
Establish guidelines for when code review (manual inspection) and/or code analysis (automated or semi-automated) should be conducted, based on organizational policies and the development stage. Apply both methods as needed for both third-party and in-house code, enhancing code quality and security throughout development.
Establish a security assurance program that defines when and how to conduct code reviews (manual inspections) and code analysis (automated or semi-automated) in accordance with organizational policies and the software development life cycle (SDLC) stage: a) Perform a security risk evaluation early in the development process to determine the appropriate level and frequency of code review and code analysis activities. b) Define and maintain security requirements for both in-house and third-party software components. These requirements guide which combination of manual inspections and automated analysis tools to use at each phase of development and maintenance. c) Incorporate security requirements into the development and maintenance processes, ensuring that code reviews and code analyses are conducted at predefined checkpoints aligned with organizational standards and the current development stage. d) Require that each software review and audit includes an evaluation of security requirements, using manual and/or automated techniques as necessary to validate compliance and identify potential vulnerabilities. e) Integrate code analysis and review into configuration management and corrective action workflows. By doing so, changes to existing software are continuously evaluated to prevent security violations, and necessary adjustments are made promptly. f) Ensure both logical and physical security controls protect the environments where code is reviewed and analyzed, maintaining the integrity and confidentiality of software and data. g) Include security assurance activities, such as code inspection and automated scanning, throughout requirements, design, implementation, testing, release, and maintenance phases. These activities should be seamlessly integrated into CI/CD pipelines, applied consistently to all software components.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-03-01-01 | Identify commonly used tools and technologies | Review existing software projects to catalog frequently used technologies, frameworks, and tools. Focus on high-level components that are widely adopted within the organization and align with its functional and security requirements. | Preparation | Senior Developers |
| SSS-02-02-03-01-02 | Curate and share a recommended list | Collaborate with senior developers, architects, managers, and security auditors to create a list of recommended tools and technologies. Consider factors such as incident history, vulnerability response, usability, and organizational expertise when selecting components. | Development | Architects |
| SSS-02-02-03-01-03 | Communicate recommendations to teams | Distribute the curated list across the organization and promote it as the default choice for project teams. Use internal documentation platforms or communication channels to ensure accessibility and adoption. | Deployment | Development Managers |
| SSS-02-02-03-01-04 | Perform periodic reviews for security and relevance | Regularly evaluate the recommended technologies to ensure they remain secure, relevant, and aligned with organizational needs. Update the list based on changes in the threat landscape, new vulnerabilities, or evolving organizational requirements. | Post-deployment | Security Auditors |
| SSS-02-02-03-01-05 | Monitor adoption and gather feedback | Track the usage of recommended tools and technologies across projects. Solicit feedback from development teams to identify challenges, improvements, or additional tools to include in future iterations of the list. | Post-deployment | Development Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PW.7.1) CISA (2.3.4 Review or analyze humn-readable code- Recommended mitigations- 1.) |
Perform code reviews and analysis following secure coding standards. Use peer reviews, involve expert reviewers, apply static analysis, employ checklists, automate issue identification and remediation, and track issues in the team’s workflow or issue tracking system. Record root causes, document lessons learned, and maintain a knowledge base. These practices reinforce code security, quality, and continuous learning within the development team.
Perform Code Reviews and/or Analysis According to Secure Coding Standards: Incorporate peer and expert reviews, tools and automation, structured checklists, and continuous improvement measures into the code review and analysis process. Use established workflows and tracking systems to document issues, prioritize remediation, and record lessons learned. Peer and Expert Reviews: Example 1: Perform peer reviews of code, and include any existing review, analysis, or testing results as part of the peer review process. Example 2: Engage expert reviewers to examine code for backdoors and other malicious content. Tools and Automation: Example 3: Utilize peer review tools that streamline the peer review process, ensuring that all discussions and feedback are documented. Example 4: Employ static analysis tools to automatically check for vulnerabilities and compliance. Have a human review reported issues and remediate them as necessary. Example 6: Continuously use automated tools to identify and remediate documented and verified unsafe software practices as code is checked into the repository. Structured Review Checklists: Example 5: Apply standardized review checklists to confirm that the code meets all specified requirements. Continuous Improvement: Example 7: Identify and document the root causes of discovered issues to prevent similar vulnerabilities in the future. Example 8: Record lessons learned from code reviews and analysis in a searchable wiki, ensuring developers can easily access and learn from past experiences.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-04-01-01 | Incorporate peer and expert reviews | Conduct peer reviews to identify potential issues in code, integrating existing analysis and testing results. Engage expert reviewers to detect advanced threats, such as backdoors or malicious content, ensuring comprehensive scrutiny. | Development | Development Teams |
| SSS-02-02-04-01-02 | Leverage tools and automation | Use peer review tools to streamline discussions and feedback while documenting all findings. Employ static analysis and automated tools to check for vulnerabilities and compliance, followed by human review to validate and remediate reported issues. | Development | DevOps Teams |
| SSS-02-02-04-01-03 | Apply structured review checklists | Use standardized review checklists to ensure the code meets all specified functional, security, and compliance requirements. This structured approach helps maintain consistency across reviews and ensures no critical checks are missed. | Deployment | Quality Assurance Teams |
| SSS-02-02-04-01-04 | Implement continuous improvement measures | Identify root causes of discovered vulnerabilities during reviews and analysis. Record lessons learned in a centralized, searchable knowledge base (e.g., a wiki) to promote organizational learning and reduce the recurrence of similar issues. | Post-deployment | Security Teams |
| SSS-02-02-04-01-05 | Track and document review results | Use established workflows and tracking systems to document issues, prioritize remediation, and track resolution progress. Maintain comprehensive records for audits and to inform future code reviews. | Post-deployment | Compliance Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PW.7.2) SSDF (PW.7.2: Perform the code review and/or code analysis- Example) |
Organizations must configure and integrate automated security testing tools within the software delivery pipeline to ensure scalability and low operational overhead. These tools should automatically execute security tests as part of the build and deployment processes, providing continuous feedback and early detection of vulnerabilities. Begin security testing as early as the requirements or design phases, adopting a test-driven development approach where security test cases are designed and executed alongside functional test cases. Unresolved test cases serve as actionable goals for developers, ensuring that all identified security gaps are resolved before implementation is considered complete. This reduces the risk of release delays due to unresolved vulnerabilities or forced risk acceptance to meet project deadlines. To improve visibility, consolidate automated and manual security test results into centralized dashboards and present the outcomes regularly to management and business stakeholders. If any findings remain as accepted risks, stakeholders and development managers must collaboratively establish clear timeframes for addressing these before release. Enhance testing processes by adopting test correlation tools that merge results from dynamic, static, and interactive security tests into a unified dashboard. These tools facilitate defect management and allow for the seamless tracking of security issues. Spread awareness of test results and findings across development teams, fostering a culture of continuous learning and proactive security improvement throughout the organization.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-04-02-01 | Configure automated security testing tools | Integrate security testing tools (e.g., SAST, DAST, IAST) into the CI/CD pipeline for automated execution during builds, deployments, and other stages of the development lifecycle. | Development | DevOps team, Security team |
| SSS-02-02-04-02-02 | Implement security test-driven development (STDD) | Design security test cases early in the requirements or design phases. Run these tests automatically, and use them to guide the implementation until all tests pass. | Development | Development teams, Security champions |
| SSS-02-02-04-02-03 | Present security test results via dashboards | Create centralized dashboards to display the results of automated and manual security tests. Regularly share these results with management and stakeholders for transparency. | Deployment | Security team, Development managers |
| SSS-02-02-04-02-04 | Correlate security test results | Use security test correlation tools to merge and centralize results from multiple scanners, such as dynamic, static, and interactive tools, into a unified view. | Deployment | DevOps team, Security team |
| SSS-02-02-04-02-05 | Establish accountability for accepted risks | Document unaddressed security findings as accepted risks, and work with stakeholders to define concrete deadlines and monitor progress for remediation. | Post-deployment | Security team, Development managers |
| SSS-02-02-04-02-06 | Continuously improve security tests | Regularly review and enhance security tests to address emerging threats and lessons learned from past testing activities. | Post-deployment | Security team, Development teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PW.7.2) OWASP SAMM: Software Assurance Maturity Model (V-ST-3-A) |
Organizations must establish a centralized system for tracking and managing security defects across all applications and development processes. This system should begin by standardizing the definition and classification of security defects to ensure consistent identification and reporting. Security defects can originate from various sources, including threat assessments, penetration tests, outputs from static and dynamic analysis scanning tools, and responsible disclosure programs or bug bounties. To foster a transparent security culture, avoid assigning blame to teams or individuals for identifying or introducing defects. Instead, focus on promoting collaboration and proactive remediation. Security defects should be recorded and tracked in a well-defined location, which need not be centralized for the entire organization but must allow a comprehensive overview of all defects affecting a specific application at any given time. Implement strict access controls to safeguard defect records and mitigate the risks of data leakage or misuse. Enhance prioritization of defect remediation efforts by introducing qualitative classifications (e.g., critical, high, medium, low) based on the risk and impact of each defect. Additionally, ensure the tracking system minimizes duplication of entries and false positives, enhancing its accuracy and reliability. By maintaining a comprehensive record of security defects, organizations can prioritize remediation, identify systemic vulnerabilities, and improve their overall security posture.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-04-03-01 | Define security defect standards | Establish a common definition and classification system for security defects, including severity levels and prioritization criteria. Ensure teams understand these definitions. | Preparation | Security team, Development teams, ,Testing teams, QA teams |
| SSS-02-02-04-03-02 | Set up a centralized defect tracking system | Implement a tool or platform (e.g., JIRA, Azure DevOps) to record and track all security defects for each application. Ensure it supports centralized or application-specific views. | Development | DevOps team, QA teams, Security team |
| SSS-02-02-04-03-03 | Integrate security defect identification sources | Connect(link) defect tracking with bug reports from threat assessments, penetration tests, static/dynamic analysis tools, and bug bounties to ensure all defects are captured effectively. | Development | Security team, Testing teams, Vendor partners |
| SSS-02-02-04-03-04 | Classify and prioritize security defects | Introduce a qualitative classification system for defects (e.g., critical, high, medium, low) and prioritize fixes based on severity and application impact. | Deployment | Security team, Development teams, Testing teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PW.7.2) OWASP SAMM: Software Assurance Maturity Model (I-DM-1-A) |
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-02-05-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-02-05-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-02-05-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-02-05-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-02-05-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-1780) 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-02-05-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-02-05-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-02-05-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-02-05-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-02-05-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-1780) 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-02-05-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-02-05-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-02-05-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-02-05-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-1780) NIST Secure Software Development Framework (PO.2.1) OWASP SAMM: Software Assurance Maturity Model (G-EG-1-A) |
Develop and enforce processes and mechanisms to gather and protect essential information supporting security criteria. Leverage the toolchain to collect and analyze data, deploy additional tools when necessary, automate decision-making where possible, and restrict access to sensitive information to authorized personnel only, enhancing security and preventing unauthorized access.
Establish a secure, centralized system for tracking and managing security defect information with strict access controls, such as role-based access control (RBAC), to ensure only authorized personnel can view or modify records. Implement qualitative classification frameworks to prioritize defects based on criticality and impact while preventing duplication and false positives. Incorporate audit trails and cryptographic integrity checks to monitor and secure defect data, ensuring accountability and data reliability. Regularly review access policies and system logs to identify and mitigate unauthorized or suspicious activities, maintaining the confidentiality and integrity of defect information.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-06-01-01 | Implement access controls | Use role-based access control (RBAC) to manage permissions for viewing, editing, and managing defect information. | Preparation | Security team |
| SSS-02-02-06-01-02 | Classify and prioritize defects | Develop a framework to classify defects based on criticality and impact to streamline remediation efforts. | Development | QA teams, Security team |
| SSS-02-02-06-01-03 | Enforce data integrity | Use cryptographic checks and audit trails to protect defect records and monitor any changes. | Deployment | Security team, DevOps team |
| SSS-02-02-06-01-04 | Review access and logs | Continuously monitor user access logs and system activities to detect and respond to unauthorized actions. | Post-deployment | Security team, Development teams |
| SSS-02-02-06-01-05 | Prevent duplication and false positives | Implement mechanisms to validate defect records, reducing errors and ensuring reliable defect data. | Development | Development teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.4.2) OWASP SAMM: Software Assurance Maturity Model (I-DM-1-A) |
Adopt best security practices for the deployment, operation, and maintenance of tools and toolchains. Select and integrate tools based on secure configurations, ensure compatibility with other tools and workflows, apply code-based configurations, and implement reproducible builds. Continuously monitor tools for integrity issues, replace outdated tools, and follow security protocols for compilers, interpreters, and build tools. These practices uphold the security and reliability of the DevOps toolchain.
Automating the build process ensures consistent and efficient execution of builds, reducing human error and improving productivity. This approach requires securing the build toolset and its interfaces to prevent tampering and unauthorized access. Proper management of credentials and secrets, such as repository keys and code signing certificates, is critical. Additionally, incorporating automated security checks like SAST tools enhances security by identifying vulnerabilities early in the development lifecycle. These measures ensure that the build process remains efficient, secure, and trustworthy.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-07-01-01 | Automate the build execution process | Implement tools to automate the build process, ensuring it runs consistently without manual intervention. Configure the build system to execute reliably at any time, minimizing human error and ensuring reproducibility. | Development | DevOps Teams |
| SSS-02-02-07-01-02 | Harden and secure build tooling | Apply security controls to build tools and their interfaces (e.g., web portals) to prevent tampering and unauthorized access. This includes network lockdowns and regular audits of exposed services to mitigate risks from potential malicious actors. | Deployment | Security Teams |
| SSS-02-02-07-01-03 | Manage credentials and sign artifacts | Securely manage credentials and secrets needed for builds, such as code signing certificates and repository access tokens. Sign generated artifacts using organizational certificates to verify their origin and ensure integrity. | Deployment | DevOps Teams |
| SSS-02-02-07-01-04 | Integrate automated security checks | Incorporate tools like Static Application Security Testing (SAST) into the automated build pipeline. Use these checks to identify and address vulnerabilities early in the development process, leveraging automation to enhance security benefits. | Post-deployment | Security Teams |
| SSS-02-02-07-01-05 | Monitor and maintain build processes | Continuously monitor the build system for anomalies and regularly update the automation tools to address new threats. Periodically review and refine the process to ensure it remains secure and aligned with evolving best practices. | Post-deployment | DevOps Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.3.2) OWASP SAMM: Software Assurance Maturity Model (I-SB-2-A) |
Automating the deployment process eliminates manual configuration steps, reducing the risk of human error and ensuring consistency across all stages. Security checks such as DAST and vulnerability scanning should be integrated into the deployment pipeline to identify and mitigate potential risks early. Deployment artifacts should be verified for integrity, and test results logged centrally to support monitoring and remediation. Critical issues should trigger automated deployment stops or initiate manual approval workflows with proper documentation. A comprehensive deployment tracking system should record every deployment's details, ensuring accountability and supporting audits.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-07-02-01 | Automate deployment processes | Set up tools to fully automate the deployment process, ensuring no manual configuration steps are required. This ensures consistency across all stages and minimizes the risk of human error. | Development | DevOps Teams |
| SSS-02-02-07-02-02 | Integrate automated security checks | Incorporate tools like DAST and vulnerability scanners into the deployment pipeline. Verify the integrity of deployed artifacts and log the results of security checks in a centralized system for monitoring and further action. | Deployment | Security Teams |
| SSS-02-02-07-02-03 | Implement automated issue handling | Configure the system to automatically notify relevant personnel of detected issues. For critical defects, automate deployment stops or introduce a manual approval process to review and document exceptions. | Deployment | DevOps Teams |
| SSS-02-02-07-02-04 | Track and audit deployments | Establish a tracking system to record all deployment details, including personnel involved, software versions, and deployment-specific variables. Use this information for accountability and audit purposes. | Post-deployment | Compliance Teams |
| SSS-02-02-07-02-05 | Review and refine deployment practices | Regularly review deployment logs and security test results to identify areas for improvement. Refine automation and security practices based on evolving threats and organizational requirements. | Post-deployment | DevOps Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.3.2) OWASP SAMM: Software Assurance Maturity Model (I-SD-2-A) |
Integrating security testing tools into the delivery pipeline ensures continuous and automated testing for vulnerabilities throughout the development lifecycle. This approach starts early in the requirements or design phases and continues through implementation, helping to identify and address security issues before release. Results from these tests should be centralized in dashboards, made visible to stakeholders, and used to guide defect management and decision-making. Developers should use security test cases as upfront goals, driving secure coding practices while improving organizational awareness and collaboration around security concerns.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-07-03-01 | Automate security testing in CI/CD pipeline | Configure security testing tools to automatically run during the build and deployment processes. Use tools like SAST, DAST, and IAST to identify vulnerabilities early in the cycle and lower the risk of release delays due to unresolved security issues. | Development | DevOps Teams |
| SSS-02-02-07-03-02 | Introduce test-driven security practices | Start security testing during the requirements or design phases. Create and run security test cases early, treating passing these tests as an essential milestone for implementation completion. This approach sets clear, upfront security goals for developers. | Development | Development Teams |
| SSS-02-02-07-03-03 | Centralize and present test results | Use dashboards to make automated and manual security test results visible to stakeholders. Present findings to management and business stakeholders before each release, establishing timelines for addressing accepted risks and unresolved issues. | Deployment | Security Teams |
| SSS-02-02-07-03-04 | Use security test correlation tools | Implement tools to match and merge results from various security scanners (e.g., static, dynamic, and interactive). Centralize the data in one dashboard to support defect management and streamline remediation efforts. | Deployment | Security Teams |
| SSS-02-02-07-03-05 | Promote security awareness and collaboration | Share security test results and knowledge across development teams. Use findings to improve security awareness and encourage collaborative efforts to enhance the quality of security tests and practices within the organization. | Post-deployment | Development Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.3.2) OWASP SAMM: Software Assurance Maturity Model (V-ST-3-A) |
Establish and maintain a repository of preferred technologies, frameworks, and tools, focusing on those widely used across the organization’s software projects. Ensure this repository includes high-level technologies vetted for security, reliability, and compatibility with organizational goals. When curating this list, assess each tool's incident history, ability to respond to vulnerabilities, functionality relevance, ease of use, and internal familiarity. Engage senior developers, architects, managers, and security auditors to collaboratively identify and validate these recommendations. Share the list across development teams as a trusted source of default tools and perform periodic reviews to address emerging security and operational needs, ensuring continuous alignment with best practices.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-07-04-01 | Identify commonly used tools and technologies | Compile a list of common tools like Spring Boot for backend development and React for frontend. | Preparation | Architects, Development leads, Security auditors |
| SSS-02-02-07-04-02 | Evaluate tools against selection criteria | Evaluate Django for security patches and community support compared to similar frameworks. | Preparation | Senior developers, Architects, Security team |
| SSS-02-02-07-04-03 | Create a recommended tools and technologies list | Publish a preferred list including tools like GitHub Actions for CI/CD and PostgreSQL for databases. | Development | Architects, Development managers, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.3.2) OWASP SAMM: Software Assurance Maturity Model (D-SA-3-B) |
Configure tools to create artifacts that demonstrate adherence to secure software development practices. Enable an audit trail using current tools, determine appropriate audit frequency, set policies for managing artifact data, and assign accountability for artifact generation. This helps maintain transparency and accountability, supporting continuous improvement in DevOps workflows.
Establish a centralized process for tracking and managing security defects to enhance accountability and transparency. Begin by defining a common understanding of what constitutes a security defect and identifying the methods to detect them, such as threat assessments, penetration tests, static and dynamic analysis tools, and responsible disclosure programs or bug bounties. Foster a blame-free culture to encourage accurate reporting and proactive mitigation of defects. Maintain a repository to log and track all identified security defects, ensuring it is accessible for relevant stakeholders to gain a comprehensive view of application risks. Define strict access controls to protect defect information from unauthorized use or leakage. Implement a qualitative classification system for defects to prioritize remediation efforts effectively and reduce duplication or false positives. Regularly review and refine the process to maintain its effectiveness and trustworthiness in improving DevOps workflows.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-08-01-01 | Define security defect standards | Establish a common definition and classification system for security defects, including severity levels and prioritization criteria. Ensure teams understand these definitions. | Preparation | Security team, Development teams, ,Testing teams, QA teams |
| SSS-02-02-08-01-02 | Set up a centralized defect tracking system | Implement a tool or platform (e.g., JIRA, Azure DevOps) to record and track all security defects for each application. Ensure it supports centralized or application-specific views. | Development | DevOps team, QA teams, Security team |
| SSS-02-02-08-01-03 | Integrate security defect identification sources | Connect(link) defect tracking with bug reports from threat assessments, penetration tests, static/dynamic analysis tools, and bug bounties to ensure all defects are captured effectively. | Development | Security team, Testing teams, Vendor partners |
| SSS-02-02-08-01-04 | Classify and prioritize security defects | Introduce a qualitative classification system for defects (e.g., critical, high, medium, low) and prioritize fixes based on severity and application impact. | Deployment | Security team, Development teams, Testing teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PO.3.3) OWASP SAMM: Software Assurance Maturity Model (I-DM-1-A) |
Implement a vulnerability disclosure program (VDP) that invites security researchers to report potential vulnerabilities in products and services. Make program details easily accessible by providing clear guidelines, contact information, and reporting channels, such as a dedicated webpage or contact email. This program fosters collaboration with the security community, enhances early vulnerability detection, and supports the continuous security improvement of products and services. It emphasizes the importance of creating a user-friendly, transparent disclosure program that encourages external security researchers to contribute to product security, directly supporting the goal of proactive vulnerability management.
Create a structured vulnerability disclosure program (VDP) to engage external security researchers in reporting vulnerabilities effectively. Include clear reporting guidelines, accessible communication channels (e.g., a dedicated webpage or email), and transparent expectations for response times and follow-up. Assign responsibility for managing the VDP to a dedicated owner or team equipped with the necessary resources to handle reported vulnerabilities promptly and securely. Ensure the program aligns with industry best practices for disclosure, fostering trust and collaboration with the research community. Protect the confidentiality of submitted reports, documenting all findings and actions taken to address vulnerabilities. Regularly review and update the program to accommodate evolving threat landscapes and maintain alignment with regulatory requirements.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-09-01-01 | Establish reporting guidelines and channels | Define clear and detailed guidelines for reporting vulnerabilities, including the format and required information. Set up accessible communication channels, such as a dedicated webpage or email, to facilitate submissions. | Preparation | Security Teams |
| SSS-02-02-09-01-02 | Assign a dedicated vdp management team | Assign responsibility for managing the VDP to a dedicated owner or team equipped with the tools and resources to handle reported vulnerabilities promptly and securely. Ensure the team is trained in secure report handling and communication. | Preparation | VDP Management Team |
| SSS-02-02-09-01-03 | Define response times and follow-up procedures | Set transparent expectations for response times, including acknowledgment of submissions, initial assessments, and resolution timelines. Develop a follow-up process to keep researchers informed about the progress and outcomes of their reports. | Development | VDP Management Team |
| SSS-02-02-09-01-04 | Protect report confidentiality and document actions | Ensure that all vulnerability reports are handled confidentially. Document all findings, decisions, and actions taken to address vulnerabilities, creating a detailed audit trail for internal use and compliance purposes. | Post-deployment | Compliance Teams |
| SSS-02-02-09-01-05 | Regularly review and update the VDP | Periodically review the VDP to ensure it aligns with evolving threat landscapes, industry best practices, and regulatory requirements. Update reporting guidelines, response procedures, and communication channels as necessary to maintain program effectiveness and trust. | Post-deployment | VDP Management Team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (RV.1.3 Example 1) OWASP SAMM: Software Assurance Maturity Model (O-IM-1-B) |
Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.
Perform Code Reviews and/or Analysis According to Secure Coding Standards: Incorporate peer and expert reviews, tools and automation, structured checklists, and continuous improvement measures into the code review and analysis process. Use established workflows and tracking systems to document issues, prioritize remediation, and record lessons learned.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-10-01-01 | Incorporate peer and expert reviews | Conduct peer reviews to identify potential issues in code, integrating existing analysis and testing results. Engage expert reviewers to detect advanced threats, such as backdoors or malicious content, ensuring comprehensive scrutiny. | Development | Development Teams |
| SSS-02-02-10-01-02 | Leverage tools and automation | Use peer review tools to streamline discussions and feedback while documenting all findings. Employ static analysis and automated tools to check for vulnerabilities and compliance, followed by human review to validate and remediate reported issues. | Development | DevOps Teams |
| SSS-02-02-10-01-03 | Apply structured review checklists | Use standardized review checklists to ensure the code meets all specified functional, security, and compliance requirements. This structured approach helps maintain consistency across reviews and ensures no critical checks are missed. | Deployment | Quality Assurance Teams |
| SSS-02-02-10-01-04 | Implement continuous improvement measures | Identify root causes of discovered vulnerabilities during reviews and analysis. Record lessons learned in a centralized, searchable knowledge base (e.g., a wiki) to promote organizational learning and reduce the recurrence of similar issues. | Post-deployment | Security Teams |
| SSS-02-02-10-01-05 | Track and document review results | Use established workflows and tracking systems to document issues, prioritize remediation, and track resolution progress. Maintain comprehensive records for audits and to inform future code reviews. | Post-deployment | Compliance Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PW.7.2) SSDF (PW.7.2: Perform the code review and/or code analysis- Example) |
Organizations must configure and integrate automated security testing tools within the software delivery pipeline to ensure scalability and low operational overhead. These tools should automatically execute security tests as part of the build and deployment processes, providing continuous feedback and early detection of vulnerabilities. Begin security testing as early as the requirements or design phases, adopting a test-driven development approach where security test cases are designed and executed alongside functional test cases. Unresolved test cases serve as actionable goals for developers, ensuring that all identified security gaps are resolved before implementation is considered complete. This reduces the risk of release delays due to unresolved vulnerabilities or forced risk acceptance to meet project deadlines. To improve visibility, consolidate automated and manual security test results into centralized dashboards and present the outcomes regularly to management and business stakeholders. If any findings remain as accepted risks, stakeholders and development managers must collaboratively establish clear timeframes for addressing these before release. Enhance testing processes by adopting test correlation tools that merge results from dynamic, static, and interactive security tests into a unified dashboard. These tools facilitate defect management and allow for the seamless tracking of security issues. Spread awareness of test results and findings across development teams, fostering a culture of continuous learning and proactive security improvement throughout the organization.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-10-02-01 | Configure automated security testing tools | Integrate security testing tools (e.g., SAST, DAST, IAST) into the CI/CD pipeline for automated execution during builds, deployments, and other stages of the development lifecycle. | Development | DevOps team, Security team |
| SSS-02-02-10-02-02 | Implement security test-driven development (STDD) | Design security test cases early in the requirements or design phases. Run these tests automatically, and use them to guide the implementation until all tests pass. | Development | Development teams, Security champions |
| SSS-02-02-10-02-03 | Present security test results via dashboards | Create centralized dashboards to display the results of automated and manual security tests. Regularly share these results with management and stakeholders for transparency. | Deployment | Security team, Development managers |
| SSS-02-02-10-02-04 | Correlate security test results | Use security test correlation tools to merge and centralize results from multiple scanners, such as dynamic, static, and interactive tools, into a unified view. | Deployment | DevOps team, Security team |
| SSS-02-02-10-02-05 | Establish accountability for accepted risks | Document unaddressed security findings as accepted risks, and work with stakeholders to define concrete deadlines and monitor progress for remediation. | Post-deployment | Security team, Development managers |
| SSS-02-02-10-02-06 | Continuously improve security tests | Regularly review and enhance security tests to address emerging threats and lessons learned from past testing activities. | Post-deployment | Security team, Development teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PW.7.2) OWASP SAMM: Software Assurance Maturity Model (V-ST-3-A) |
Organizations must establish a centralized system for tracking and managing security defects across all applications and development processes. This system should begin by standardizing the definition and classification of security defects to ensure consistent identification and reporting. Security defects can originate from various sources, including threat assessments, penetration tests, outputs from static and dynamic analysis scanning tools, and responsible disclosure programs or bug bounties. To foster a transparent security culture, avoid assigning blame to teams or individuals for identifying or introducing defects. Instead, focus on promoting collaboration and proactive remediation. Security defects should be recorded and tracked in a well-defined location, which need not be centralized for the entire organization but must allow a comprehensive overview of all defects affecting a specific application at any given time. Implement strict access controls to safeguard defect records and mitigate the risks of data leakage or misuse. Enhance prioritization of defect remediation efforts by introducing qualitative classifications (e.g., critical, high, medium, low) based on the risk and impact of each defect. Additionally, ensure the tracking system minimizes duplication of entries and false positives, enhancing its accuracy and reliability. By maintaining a comprehensive record of security defects, organizations can prioritize remediation, identify systemic vulnerabilities, and improve their overall security posture.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-02-10-03-01 | Define security defect standards | Establish a common definition and classification system for security defects, including severity levels and prioritization criteria. Ensure teams understand these definitions. | Preparation | Security team, Development teams, ,Testing teams, QA teams |
| SSS-02-02-10-03-02 | Set up a centralized defect tracking system | Implement a tool or platform (e.g., JIRA, Azure DevOps) to record and track all security defects for each application. Ensure it supports centralized or application-specific views. | Development | DevOps team, QA teams, Security team |
| SSS-02-02-10-03-03 | Integrate security defect identification sources | Connect(link) defect tracking with bug reports from threat assessments, penetration tests, static/dynamic analysis tools, and bug bounties to ensure all defects are captured effectively. | Development | Security team, Testing teams, Vendor partners |
| SSS-02-02-10-03-04 | Classify and prioritize security defects | Introduce a qualitative classification system for defects (e.g., critical, high, medium, low) and prioritize fixes based on severity and application impact. | Deployment | Security team, Development teams, Testing teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1780) NIST Secure Software Development Framework (PW.7.2) OWASP SAMM: Software Assurance Maturity Model (I-DM-1-A) |