Welcome · Secure Delivery Framework

This objective, and the other similar ‘Approach For‘ objectives, simply state what has to be in your Agreed Ways Of Working for the Product Delivery Organisation. You may want to include more, but you cannot be missing any of these and still run a secure Product Delivery Organisation.

Group or Individual: Product Delivery Organisation
Artefact: Agreed Ways Of Working
Concepts: Security Component Testing
Capabilities: Quality Control
Document: Approach For Security Component Testing
Risk Type: Feasibility
Event: A security vulnerability is identified by somebody outside of the Organisation
Caused By: Product Teams not identifying and remediating discoverable product insecurities as part of delivery
Leading To: Increased cost for remediation, impact on delivery or increased risk of a Security Incident
I-SB-B-1-1 Implementation > Secure Build > Software Dependencies: Do you have solid knowledge about dependencies you're relying on?
V-RT-B-1-1 Verification > Requirements-driven Testing > Misuse/Abuse Testing: Do you test applications using randomization or fuzzing techniques?
V-RT-B-3-1 Verification > Requirements-driven Testing > Misuse/Abuse Testing: Do you perform denial of service and security stress testing?
V-ST-A-1-1 Verification > Security Testing > Scalable Baseline: Do you scan applications with automated security testing tools?

This objective, and the other similar ‘include‘ objectives, simply state what work has to be included as part of Product Security Work. You may want to include more, but you cannot be missing any of these and still deliver a secure Product.

Group or Individual: Product Team
Artefact: Product Security Work
Concepts: Security Component Testing
Capabilities: Quality Control
Document: Product Security Work
Risk Type: Feasibility
Event: A security vulnerability is identified by somebody outside of the Organisation
Caused By: Product Teams not identifying and remediating discoverable product insecurities as part of delivery
Leading To: Increased cost for remediation, impact on delivery or increased risk of a Security Incident
V-ST-B-3-1 Verification > Security Testing > Deep Understanding: Do you use the results of security testing to improve the development lifecycle?
I-DM-A-1-1 Implementation > Defect Management > Defect Tracking: Do you track all known security defects in accessible locations?
I-DM-B-1-1 Implementation > Defect Management > Metrics and Feedback: Do you use basic metrics about recorded security defects to carry out quick win improvement activities?

This objective, and the other similar ‘include‘ objectives, simply state what has to be in your Product Security Levels for the Product Delivery Organisation. You may want to include more, but you cannot be missing any of these and still run a secure Product Delivery Organisation.

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Security Component Testing
Capabilities: Quality Control
Document: Objectives For Security Component Testing
Risk Type: Feasibility
Event: A security vulnerability is identified by somebody outside of the Organisation
Caused By: Product Teams not identifying and remediating discoverable product insecurities as part of delivery
Leading To: Increased cost for remediation, impact on delivery or increased risk of a Security Incident
I-SD-A-2-1 Implementation > Secure Deployment > Deployment Process: Are deployment processes automated and employing security checks?

Security Component Testing

Policy Viewer

Security Component Testing Objectives (3)

Security Component Testing

Policy Viewer

Security Component Testing Objectives (3)

Product Delivery Organisation MUST include Approach For Security Component Testing as part of Agreed Ways Of Working

Product Team MUST include Product Security Work identified through Approach For Security Component Testing

Technology Community Of Practice MUST include Objectives For Security Component Testing as part of Product Security Levels