[ISM] Vulnerability resolution:

[SSDF] Analyze vulnerability risks for prioritization (SSS-04-06-01)

Thoroughly analyze each identified vulnerability to understand the risk it poses and to inform a suitable remediation or risk response plan. Document vulnerabilities in an issue tracking system, and assess their risk by considering factors such as exploitability, potential impact, and severity. Use these risk calculations to prioritize remediation efforts, ensuring that the most critical vulnerabilities are addressed promptly while maintaining an efficient vulnerability management process. It highlights the importance of structured documentation, risk assessment, and prioritization to enable timely and effective resolution of vulnerabilities.

[SAMM] Rate and track security defects consistently (SSS-04-06-01-01)

Implement a structured and organization-wide methodology to rate and prioritize security defects based on exploitability, potential impact, and severity. Store information about these defects centrally or ensure easy aggregation from distributed sources to identify high-risk areas requiring immediate attention. Establish service-level agreements (SLAs) for fixing defects according to their criticality, and monitor SLA adherence regularly. For cases where fixing a defect within SLA is impractical or uneconomical, define compensating controls and ensure all stakeholders clearly understand the associated risks. Even for low-severity issues without formal SLAs, provide regular updates to ensure awareness across teams about defects impacting their systems and any cumulative risks these defects might create. This consistent approach helps maintain focus on critical vulnerabilities, facilitates clear communication among stakeholders, and ensures timely and effective risk mitigation.

Operations

ID	Operation	Description	Phase	Agent
SSS-04-06-01-01-01	Define and apply a security defect rating methodology	Use CVSS (Common Vulnerability Scoring System) to assign severity ratings like Critical, High, Medium, or Low.	Development	Security team, Risk management team
SSS-04-06-01-01-02	Centralize security defect tracking	Implement tools like JIRA or ServiceNow for centralized defect tracking and reporting.	Development	Security team, Development leads
SSS-04-06-01-01-03	Introduce slas for defect resolution	Set SLAs such as 30 days for High severity defects and 90 days for Medium severity defects, with daily reminders for overdue issues.	Deployment	Security team, Development managers

References

Industry framework	Academic work	Real-world case
Information Security Manual (ISM-1754) NIST Secure Software Development Framework (RV.2.1) OWASP SAMM: Software Assurance Maturity Model (I-DM-2-A)

[SSDF] Implement risk-based remediation plans (SSS-04-06-02)

Develop and execute a risk response plan for each identified vulnerability, making remediation decisions based on risk severity and potential impact. Where immediate fixes are not feasible, implement temporary mitigations to reduce risk exposure. Issue security advisories to inform stakeholders of known vulnerabilities, and use automated mechanisms to deploy remediations swiftly and consistently. Update all relevant records to reflect actions taken, ensuring transparency and accountability throughout the vulnerability management process. This emphasizes a comprehensive, risk-based approach to managing vulnerabilities, ensuring timely, informed responses and clear communication to minimize risk exposure.

[S2C2F] Establish an OSS incident response plan (SSS-04-06-02-01)

Develop a defined, repeatable process for addressing open-source software (OSS) vulnerabilities and incidents. This plan should prioritize timely and efficient remediation based on severity and potential business impact. Include mechanisms to issue advisories to stakeholders about known vulnerabilities and outline steps for applying temporary mitigations or automated fixes when immediate solutions are not feasible. Integrate this response plan into your overall vulnerability management framework, ensuring all updates and actions are documented to maintain transparency and accountability. Regularly review and refine the process to adapt to evolving threats, fostering a proactive and responsive approach to OSS security incidents.

Operations

ID	Operation	Description	Phase	Agent
SSS-04-06-02-01-01	Establish an oss incident response framework	Document the steps for OSS incident handling, including triage, investigation, and resolution, in an internal wiki.	Preparation	Security team, Risk management team
SSS-04-06-02-01-02	Triage and assess vulnerabilities	Use CVSS scores and contextual data (e.g., usage in critical services) to prioritize a vulnerability in log4j as Critical.	Development	Security team, Development managers
SSS-04-06-02-01-03	Implement risk responses and temporary mitigations	Deploy a WAF rule to block exploitation of a vulnerable OSS library while patching systems during the next maintenance window.	Deployment	Security team, DevOps team
SSS-04-06-02-01-04	Communicate and deliver remediations	Publish a customer-facing advisory about a patched OSS vulnerability and deploy the updated library using Jenkins pipelines.	Deployment	Security team, PR team, Development teams

References

Industry framework	Academic work	Real-world case
Information Security Manual (ISM-1754) NIST Secure Software Development Framework (RV.2.2) S2C2F: Secure Supply Chain Consumption Framework (INV-2)