+D-SR-B Stream B: Supplier Security
---+D-SR-1-B Perform vendor assessments
---+D-SR-2-B Discuss security responsibilities with suppliers
---+D-SR-3-B Align security methodology with suppliers

D-SR-B Stream B: Supplier Security

Supplier security deals with requirements that are relative to supplier organizations within the development context of the application, in particular for outsourced development.

1. Översikt

D-SR-1-B Perform vendor assessments

Maturity level 1 objective of the practice: Consider security explicitly during the software requirements process.

Benefit: Transparency of security practices of your software suppliers

Short description: Evaluate the supplier based on organizational security requirements.

The security competences and habits of the external suppliers involved in the development of your software can have a significant impact on the security posture of the final product. Consequently, it is important to know and evaluate your suppliers on this front.

Carry out a vendor assessment to understand the strengths and weaknesses of your suppliers. Use a basic checklist or conduct interviews to review their typical practices and deliveries. This gives you an idea of how they organize themselves and elements to evaluate whether you need to take additional measures to mitigate potential risks. Ideally, speak to different roles in the organization, or even set up a small maturity evaluation to this end. Strong suppliers will run their own software assurance program and will be able to answer most of your questions. If suppliers have weak competences in software security, discuss with them how and to what extent they plan to work on this and evaluate whether this is enough for your organization. A software supplier might be working on a low-risk project, but this could change.

It is important that your suppliers understand and align to the risk appetite and are able to meet your requirements in that area. Make what you expect from them explicit and discuss this clearly.
D-SR-2-B Discuss security responsibilities with suppliers

Maturity level 2 objective of the practice: Increase granularity of security requirements derived from business logic and known risks.

Benefit: Clearly defined security responsibilities of your software suppliers

Short description: Build security into supplier agreements in order to ensure compliance with organizational requirements.

Increase your confidence in the capability of your suppliers for software security. Discuss concrete responsibilities and expectations from your suppliers and your own organization and establish a contract with the supplier. The responsibilities can be specific quality requirements or particular tasks, and minimal service can be detailed in a Service Level Agreement (SLA). A quality requirement example is that they will deliver software that is protected against the OWASP Top 10, and in case issues are detected, these will be fixed. A task example is that they have to perform continuous static code analysis, or perform an independent penetration test before a major release. The agreement stipulates liabilities and caps in case an important issue arises.

Once you have implemented this for a few suppliers, work toward a standard agreement for suppliers that forms the basis of your negotiations. You can deviate from this standard agreement on a case-by-case basis, but it will help you to ensure you do not overlook important topics.
D-SR-3-B Align security methodology with suppliers

Maturity level 3 objective of the practice: Mandate security requirements process for all software projects and third-party dependencies.

Benefit: Alignment of software development practices with suppliers to limit security risks

Short description: Ensure proper security coverage for external suppliers by providing clear objectives.

The best way to minimize the risk of issues in software is to align maximally and integrate closely between the different parties. From a process perspective, this means using similar development paradigms and introducing regular milestones to ensure proper alignment and qualitative progress. From a tools perspective, this might mean using similar build, verification and deployment environments, and sharing other supporting tools (e.g. requirements, architecture tools, or code repositories).

In case suppliers cannot meet the objectives that you have set, implement compensating controls so that, overall, you meet your objectives. Execute extra activities (e.g., threat modeling before starting the actual implementation cycle) or implement extra tooling (e.g., third-party library analysis at solution intake). The more suppliers deviate from your requirements, the more work will be required to compensate.

1.1 Referenser

1.2 Identifierade krav

1.3 Relaterade regleringar

2. Identifierade krav

Krav

3. Relaterade regleringar

Regleringar
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.