OWASP SPVS V1.3:
Documenting software pipeline and its risk assessment

In my previous post, we secured developer machines. Now we move to the third subcategory of the OWASP SPVS Plan stage: V1.3 Security Requirements and Risk Assessment.

If your team does not have clear requirements, every developer will interpret "secure" differently. This creates chaos, inconsistent decisions, and hidden gaps in the pipeline.

This subcategory provides a single baseline for everyone: how the pipeline works, what critical risks are present, and what mandatory security rules are in place.

Level 1: Foundational

This level involves writing the security baseline that must be reviewed and followed by all team members.

V1.3.1 Software pipeline documentation

All pipeline steps must be documented and maintained in tandem with code changes. The documentation cannot be outdated, so it has to be updated when pipeline steps change during project development.

If a pipeline is outdated or documentation doesn't exist, you don't have the whole overview of the pipeline steps and which steps are contained, and what their purpose is. Then, if a lead developer leaves the company, you lose all knowledge about the pipeline. Also, you have trouble during incident response.

Implementation Best Practices

• Store pipeline documentation in the same repository as pipeline code or store it separately but version it in relation to code.

• Require documentation updates when pipeline behavior changes. On GitHub, you can set it as a required status check in branch protection rules – when a pipeline file is updated, then the docs must be updated too to pass the pipeline.

  Example GitHub Actions check:

  - name: pipeline docs update check
    shell: bash
    run: |
      BASE_SHA="${{ github.event.pull_request.base.sha }}"
      HEAD_SHA="${{ github.event.pull_request.head.sha }}"
      CHANGED_FILES="$(git diff --name-only "$BASE_SHA" "$HEAD_SHA")"
  
      if echo "$CHANGED_FILES" | grep -q '^\.github/workflows/'; then
        if ! echo "$CHANGED_FILES" | grep -q '^docs/pipeline\.md$'; then
          echo "ERROR: Workflow changed, but documentation was not updated!"
          exit 1
        fi
      fi
  

• Add an architecture diagram showing the whole flow from build to deploy.

• Include owners for each stage to ensure there is a person responsible for each step.

V1.3.2 Secure Development Policy covers at least OWASP Top 10 CI/CD Security Risks

Your Secure Development Policy contains rules that protect you from certain risks. It should cover at least the risks from the OWASP Top 10 CI/CD Security Risks.

If the policy contains too generic rules, without clear control descriptions, people may skip important controls because they weren't explicitly mentioned in the policy.

Implementation Best Practices

• Create the policy document with described mandatory controls and strict rules, not only recommendations.
• Map policy rules to risks, especially from the OWASP Top 10 CI/CD Security Risks.
• Define controls for pull requests, secrets handling, dependency usage, and release approvals.
• Review policy and keep it updated.

V1.3.4 Security Policy related to Secrets/Credentials

We described the requirements related to secrets in the previous post, Hardening Identity and Access Management: OWASP SPVS first line of defence. So you know the requirements, but you have to cover them in your policy.

Your policy has to cover secrets handling – how secrets are created, stored, rotated, and revoked.

Secrets can be the fastest way to break into systems. One hardcoded token leaked or exposed CI variable can compromise the production environment.

Implementation Best Practices

• Explicitly prohibit hardcoded credentials in source code and pipeline configuration. Describe a Husky (or similar pre-commit checks) configuration to prevent committing them, but also describe server-side controls such as secret scanning and push protection.
• Describe the configuration of centralized secrets storage (Secret Manager or Vault).
• Define a rotation schedule and rotate immediately after compromise.

V1.3.5 Developers reviewed Secure Development Policy

Paper will take anything; a written policy that is unknown to all team members is worthless. Developers must review and confirm the acknowledgement of it.

Implementation Best Practices

• Include Secure Development Policy acknowledgment in the onboarding process for new employees.
• Existing employees have to review the policy regularly (e.g., every half a year) or when a major change is coming.
• Create a policy acknowledgement confirmation method, e.g., a signing checklist or filling in an internal form with a little quiz to make sure the employee has understood the most important requirements.

Level 2: Standard

Level 2 comes with only one requirement: secure open source 3rd party code usage.

V1.3.3 Secure OSS policy is established

These days, almost every project has only 10% of its own code; the remaining 90% of the codebase comes from 3rd party open source packages. This is normal; you don't have to write your own framework. Just use Angular or React for the frontend. Even if it's not your code, you use it in your project, so you're responsible for managing these dependencies.

A Secure OSS Policy defines what packages are allowed, how they are evaluated, and when they must be updated or removed.

Implementation Best Practices

• Approve dependencies based on maintenance activity, license, and vulnerability history.
• Require lock files and pinning to control versions.
• Define steps for patching critical vulnerabilities in dependencies.
• Establish clear rules for abandoned packages and their replacement.

Level 3: Advanced

There are no new requirements for Level 3; the requirements from Level 2 are sufficient.

Checklist for OWASP SPVS V1.3 Security Requirements and Risk Assessment

Level 1 (Foundational)

• V1.3.1 All steps of the software pipeline are documented and maintained when code changes are made
• V1.3.2 Secure Development Policy covers at least OWASP Top 10 CI/CD Security Risks
• V1.3.4 Security Policy defines secret and credential handling rules
• V1.3.5 Developers reviewed and acknowledged the Secure Development Policy

Level 2 (Standard)

• V1.3.3 Secure OSS policy is established

What's Next?

Now we set the security rules and risk requirements for the pipeline. In the next post, we will go to the next subcategory of OWASP SPVS plan phase: V1.4 Developer Tool Operation and secure the tools that developers use every day to work on a project, like IDEs and its plugins.

Links:

• Official OWASP SPVS Project Page
• SPVS 1.0 Documentation on GitHub
• OWASP Top 10 CI/CD Security Risks