DevSecOps Software Vendor Due Diligence Guide

Secure development evidence

• Ask how secure-development practices are embedded in planning, coding, review, testing and release rather than relying on a policy statement alone.
• Review dependency inventory, vulnerability scanning, secret handling and update processes for third-party components.
• Confirm how security findings are prioritized, fixed, verified and communicated to the customer.

Pipeline and environment controls

• Review separation of development, test and production access and the controls around privileged deployment actions.
• Ask how build artifacts, dependencies and deployment configuration are made reproducible and traceable.
• Require an incident and rollback path suitable for the operational impact of the software.

Contract and operating model

• Define security responsibilities, remediation expectations, disclosure process and post-delivery support in the commercial scope.
• Retain customer access to code, documentation and operational evidence needed to change supplier if necessary.
• Reassess material architecture, dependency or hosting changes rather than treating due diligence as a one-time questionnaire.

Professional references

These references establish the standards, technical framework or authoritative engineering context used for this page. Vendor commercial terms are not used as engineering evidence.

• NIST SP 800-218 Secure Software Development Framework — NIST secure-software-development practices for supplier and SDLC evaluation.
• NIST NCCoE DevSecOps resources — Current NIST implementation resources mapping secure-development practices into DevSecOps workflows.

Commercial independence

PROFENG may display a separately disclosed approved partner after the engineering content. Partner status never changes formulas, conversion factors, procurement criteria, technical references or calculation results. Pending and unapproved programs remain hidden.