Use this when the policy is missing, when it was copied from a template, or when auditors will sample changes and the team wants the policy to describe what the pipeline proves. You get three documents in a new folder, ./secure-development-policy-from-pipeline/: a table of what your build and release pipeline actually enforces today, repository by repository (enforcement-inventory.md); a draft secure development policy of three to five pages that only promises what that table shows (secure-development-policy.md); and a list of gaps and decisions for the engineering lead (decisions.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The engineering lead approves the policy.

Inputs to gather

Read, without changing anything: the repositories' pipeline definitions, code owner files, dependency update configuration, infrastructure-as-code, release and deployment scripts, and any repository or organisation settings export the reader provides (branch rules, required checks, who can bypass them). Read the incident log for change-related outages and past security findings. Ask the reader, in one message: which repositories reach production, who can deploy, whether the company ships software or devices to customers in the EU, and whether production data is ever used outside production.

Step 1: pick the repositories

All repositories that reach production are in scope. If there are many, inventory all for branch rules and required checks (cheap), and read pipelines in depth for the five with the most deployments plus any that handle payments, authentication or personal data. Record the selection in the enforcement table.

Step 2: inventory what is enforced

For each practice, record where it is enforced (file path or setting), its scope (all in-scope repositories, some, none), its strength and its bypasses: