Unauthorised access to the authoritative source for software is prevented.
Establish comprehensive security criteria for software checks to enable robust and consistent access control throughout the Software Development Life Cycle (SDLC). These criteria should define clear policies and procedures for access management, ensuring that only authorized individuals and processes can interact with software components at every stage of development, testing, deployment, and maintenance. Additionally, conduct thorough reviews and evaluations, confirm secure configurations, verify the origin and authenticity of components, and establish controlled repositories. Maintain an approved list of trusted components, designate essential components, implement stringent update processes, and build binaries directly from source code when necessary to prevent the use of unauthorized or insecure components.
Define measurable security metrics, such as KPIs, KRIs, and vulnerability severity scores, to assess risk management. Embed these criteria into SDLC workflows, like Agile's "Definition of Done" or CI/CD checks. Review artifacts to ensure compliance with benchmarks and track outcomes (approvals, rejections, exceptions) in a centralized system. Analyze collected data to refine security practices and adapt criteria to evolving risks, ensuring a secure and consistent development process.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-01-04-01-01-01 | Define security metrics and criteria | Establish clear metrics, such as KPIs, KRIs, and vulnerability severity scores, to measure the effectiveness of software security risk management. Ensure these metrics provide meaningful insights into security risk management. | Preparation | Security Teams, Risk Management Teams |
| SSS-01-04-01-01-02 | Integrate security criteria into development workflows | Add software security criteria to existing workflows, such as the Definition of Done in agile SDLC methodologies. Ensure that security checks are an integral part of the software development lifecycle and align with project goals. | Development | Development Teams, Security Teams |
| SSS-01-04-01-01-03 | validate artifacts against security criteria | Review artifacts generated during the software development workflow (e.g., code reviews, test results, documentation) to verify they meet established security criteria. Record approvals, rejections, and exceptions as part of the workflow tracking system. | Deployment | Quality Assurance Teams, Security Analysts |
| SSS-01-04-01-01-04 | Analyze security data for continuous improvement | Collect and analyze data from security checks, including successes, failures, and exception requests, to evaluate the overall effectiveness of security measures. Use the insights gained to refine the SDLC and enhance future security practices. | Post-deployment | Security Teams, Risk Management Teams |
| SSS-01-04-01-01-05 | Track and report security check outcomes | Maintain a record of security check outcomes, including approvals, rejections, and exception requests, within the tracking system. Use these records for reporting, auditing, and identifying areas for improvement in the software development process. | Post-deployment | Security Teams, Compliance Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1422) NIST Secure Software Development Framework (PO.4.1) SSDF (PO.4.1: Define criteria for software security checks and track throughout the SDLC. - Example) |
Conduct comprehensive vendor assessments to ensure that external suppliers involved in software development align with the organization’s security standards and risk appetite. Use structured approaches, such as checklists, interviews, or maturity evaluations, to evaluate suppliers’ security practices, processes, and software assurance programs. Assess their ability to address potential risks and ensure alignment with your organization’s access control and security requirements across the SDLC. If gaps in security capabilities are identified, collaborate with suppliers to address these issues and evaluate their plans for improvement. Make security expectations explicit, provide clear guidelines, and regularly reassess supplier performance to account for changing risk factors. This ensures that external suppliers do not introduce vulnerabilities into the development process and supports a secure and consistent SDLC.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-01-04-01-02-01 | Establish vendor evaluation criteria | Define evaluation criteria based on organizational security needs and risk appetite. Use a basic checklist or conduct interviews to review their typical practices and deliveries. | Preparation | Procurement team, Security team, Project leads |
| SSS-01-04-01-02-02 | Conduct vendor assessments | Perform assessments using interviews or questionnaires with different roles in the organization. Evaluate their practices, deliveries, and software assurance processes. Include a maturity evaluation where needed. | Development | Security team, Vendor managers |
| SSS-01-04-01-02-03 | Document and prioritize identified risks | If suppliers have weak competences in software security, record vendor security risks, categorize them based on severity, and determine which risks require immediate mitigation or long-term monitoring. | Development | Security team, Procurement team, Vendors |
| SSS-01-04-01-02-04 | Communicate expectations and monitor alignment | Clearly communicate expectations to suppliers and monitor their compliance. Reassess periodically for critical or evolving projects. | Post-deployment | Procurement team, Security team, Project leads |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1422) NIST Secure Software Development Framework (PO.4.1) OWASP SAMM: Software Assurance Maturity Model (D-SR-1-B) |
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-01-04-02-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-01-04-02-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-01-04-02-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-01-04-02-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-01-04-02-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-1422) NIST Secure Software Development Framework (PO.4.2) OWASP SAMM: Software Assurance Maturity Model (I-DM-1-A) |
Secure all code forms—including source code, executable code, and configuration-as-code—using the principle of least privilege. Store code in a restricted-access repository, enforce version control and commit signing, conduct code owner reviews, and apply cryptographic protections. These measures ensure that only authorized personnel and tools can access or modify the code, safeguarding its integrity and preventing unauthorized access.
Protect application secrets and credentials stored in configuration files and code to ensure compliance with the principle of least privilege and maintain production system security. Developers should not have direct access to production secrets. Implement mechanisms to safeguard secrets, such as assigning authorized personnel to add secrets to configuration files during deployment, adhering to the separation of duty principle, and encrypting all production secrets stored in configuration files and ensuring encryption-at-rest. Avoid storing production secrets in configuration files used for development or testing environments, as these typically have lower security postures. Additionally, ensure that sensitive credentials and secrets are not left unprotected in code repositories. Use purpose-built tools for secure storage and key management to enforce access controls, allowing only authorized personnel responsible for production deployments to handle these secrets. This approach minimizes the risk of unauthorized access and ensures the integrity and confidentiality of sensitive data.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-01-04-03-01-01 | Use secret management tools | Implement tools like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault to securely store and manage production secrets, ensuring encryption at rest. | Development | DevOps team, Security team |
| SSS-01-04-03-01-02 | Encrypt secrets in configuration files | Encrypt any secrets included in configuration files before deployment. Use encryption keys stored in secure key management systems. | Deployment | DevOps team, Security team |
| SSS-01-04-03-01-03 | Enforce separation of duties | Ensure only authorized personnel can add or access production secrets in configuration files. Developers should not have direct access to production credentials. | Deployment | Security team, Operations team |
| SSS-01-04-03-01-04 | Restrict secrets to appropriate environments | Separate secrets for production, testing, and development environments. Do not reuse production secrets in lower-security environments like development or testing. | Development | Security team, Development teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1422) NIST Secure Software Development Framework (PS.1.1) OWASP SAMM: Software Assurance Maturity Model (I-SD-1-B) |