Non-Functional Requirements (NFRs) Framework for Software Systems

Overview

Software Supply Chain Security Non-Functional Requirements (NFRs) define how software source code, dependencies, open-source components, third-party libraries, build pipelines, artifacts, containers, deployment packages, infrastructure definitions, vendor-provided software, and release processes must be protected, verified, traced, validated, and governed.

These requirements are distinct from general application security because they focus on the trustworthiness of the software production and delivery path. They help teams manage risk from compromised dependencies, weak repositories, tampered build processes, unsigned artifacts, vulnerable containers, unvalidated Infrastructure as Code (IaC), and insufficient vendor attestations.

Best Practice: Define source code integrity and repository control non-functional requirements

Description

Source code integrity and repository control NFRs define how code repositories are protected from unauthorized changes, unreviewed changes, tampering, branch bypass, unsafe merges, and loss of traceability. They should address branch protection, commit identity, pull request review, administrative access, protected tags, and repository audit logging.

Benefits

Strong repository controls reduce the risk that malicious, accidental, or unreviewed changes enter the codebase and create downstream build, release, security, or compliance failures.

Example non-functional requirements

• Production-bound source code shall require pull request review and approval before merge into protected branches.

• Validation method: Validate by reviewing repository branch protection settings, pull request approval history, and merge audit records.

• Example validation evidence: Branch protection configuration, pull request records, approval logs, repository audit logs, and release traceability record.

• Repository administrative access shall be restricted to approved roles and reviewed on a recurring schedule.

• Validation method: Validate through repository permission review, privileged access review, and comparison against approved role assignments.

• Example validation evidence: Repository access export, privileged access review, access recertification record, and security approval.

Related stakeholders

Typical stakeholders include developers, engineering managers, DevSecOps teams, security teams, release managers, platform teams, and audit stakeholders.

Related lifecycle phases

Repository control NFRs are defined during engineering standards and DevSecOps design; validated during repository onboarding, development, release readiness, access review, and audit review.

Best Practice: Define dependency and open-source component non-functional requirements

Description

Dependency and open-source component NFRs define how software packages, libraries, frameworks, plugins, modules, base images, and other externally sourced components are selected, approved, scanned, updated, replaced, and governed. They should address allowed sources, version control, licensing, known vulnerabilities, component age, maintainership, and exception handling.

Benefits

Dependency requirements reduce the risk that vulnerable, abandoned, malicious, incompatible, or legally problematic components are introduced into the software system.

Example non-functional requirements

• All production dependencies shall come from approved package sources and shall be scanned for known vulnerabilities and license issues before release.

• Validation method: Validate through software composition analysis, dependency inventory review, package source review, and release readiness review.

• Example validation evidence: Software composition analysis report, dependency inventory, license review record, package source configuration, and release approval.

• Dependencies with critical known vulnerabilities shall be remediated, replaced, or formally risk-accepted before production deployment.

• Validation method: Validate by comparing dependency scan findings against remediation tickets, replacement evidence, retest results, and exception approvals.

• Example validation evidence: Dependency scan results, remediation tickets, upgrade evidence, retest report, and risk acceptance record.

Related stakeholders

Typical stakeholders include developers, security teams, legal/compliance stakeholders, open-source governance teams, platform teams, release managers, and product owners.

Related lifecycle phases

Dependency NFRs are defined during engineering standards, architecture, and release governance; validated during development, CI/CD scanning, release readiness, recurring vulnerability review, and audit review.

Best Practice: Define Software Bill of Materials (SBOM) non-functional requirements

Description

Software Bill of Materials (SBOM) NFRs define when an SBOM is required, what it must include, how it is generated, where it is stored, how it is protected, how it is updated, and how it is used for vulnerability response, supplier review, and audit evidence.

Benefits

SBOM requirements improve visibility into software composition, support faster vulnerability impact analysis, improve supplier accountability, and create evidence for software supply chain governance.

Example non-functional requirements

• Each production release shall generate and retain an SBOM that identifies direct and transitive software components, versions, package sources, and related metadata.

• Validation method: Validate through pipeline review and SBOM inspection to confirm generation, completeness, retention, and traceability to the released artifact.

• Example validation evidence: Generated SBOM, pipeline logs, artifact identifier, component inventory review, retention record, and release evidence.

• The SBOM shall be updated when production dependencies change and shall be available for security, audit, vulnerability response, and supplier review.

• Validation method: Validate by sampling releases with dependency changes and confirming that the SBOM was regenerated, stored, and linked to the release record.

• Example validation evidence: SBOM version history, release notes, dependency change record, evidence repository link, and audit sample evidence.

Related stakeholders

Typical stakeholders include security teams, DevSecOps teams, developers, release managers, vendor management, legal/compliance stakeholders, and audit stakeholders.

Related lifecycle phases

SBOM NFRs are defined during software supply chain governance and release management; validated during CI/CD execution, release readiness, vulnerability response, supplier review, and audit review.

Best Practice: Define build pipeline security and isolation non-functional requirements

Description

Build pipeline security and isolation NFRs define how build systems, runners, agents, credentials, environments, scripts, permissions, plugins, and network access are protected. They should address least privilege, environment isolation, trusted runners, secure variables, approval gates, pipeline change control, and separation between build, test, and production deployment permissions.

Benefits

Secure pipeline requirements reduce the risk that attackers or accidental changes compromise the build process, inject malicious artifacts, expose secrets, or bypass release controls.

Example non-functional requirements

• Production release pipelines shall use approved build runners and shall restrict access to production deployment credentials to approved pipeline stages only.

• Validation method: Validate through pipeline configuration review, runner configuration review, credential access review, and test execution of pipeline permission boundaries.

• Example validation evidence: Pipeline configuration export, runner configuration, credential policy, access test results, and security approval.

• Changes to production deployment pipeline definitions shall require peer review, approval, and traceable change history.

• Validation method: Validate by reviewing pipeline-as-code repository controls, change records, approvals, and audit logs.

• Example validation evidence: Pipeline pull request records, approval history, repository logs, change ticket, and release governance evidence.

Related stakeholders

Typical stakeholders include DevSecOps teams, platform engineers, developers, release managers, security teams, infrastructure teams, and audit stakeholders.

Related lifecycle phases

Pipeline security NFRs are defined during CI/CD design and engineering standards; validated during pipeline implementation, release readiness, security review, access review, and recurring control review.

Best Practice: Define build integrity and artifact provenance non-functional requirements

Description

Build integrity and artifact provenance NFRs define how teams prove what source, dependencies, build steps, tools, identities, timestamps, and environments produced a software artifact. They should address build reproducibility, provenance metadata, tamper detection, custody, traceability, and provenance retention.

Benefits

Build integrity and provenance requirements help teams verify that released artifacts came from approved sources and build processes. They support incident response, audit, vulnerability impact analysis, and release trust.

Example non-functional requirements

• Each production artifact shall be traceable to the source commit, dependency set, build pipeline execution, build environment, and release approval that produced it.

• Validation method: Validate by tracing a sampled production artifact back to source commit, build logs, dependency records, and release approval records.

• Example validation evidence: Artifact metadata, commit hash, build logs, dependency snapshot, release approval, and provenance record.

• Production artifacts shall include or be linked to provenance metadata sufficient to identify the build process and source inputs used to produce the artifact.

• Validation method: Validate through provenance metadata inspection and comparison against pipeline and source control records.

• Example validation evidence: Provenance attestation, pipeline execution record, source control link, artifact registry metadata, and release evidence.

Related stakeholders

Typical stakeholders include DevSecOps teams, release managers, developers, security teams, platform teams, incident response teams, and audit stakeholders.

Related lifecycle phases

Build integrity NFRs are defined during CI/CD design and release governance; validated during build execution, release readiness, artifact promotion, vulnerability response, incident review, and audit review.

Best Practice: Define artifact signing and verification non-functional requirements

Description

Artifact signing and verification NFRs define how build outputs, packages, container images, deployment bundles, and release artifacts are cryptographically signed and verified before use. They should define approved signing keys, key custody, signing process, signature verification point, failure behavior, and evidence retention.

Benefits

Artifact signing requirements help prevent tampered or untrusted artifacts from being deployed. They also strengthen release integrity, platform admission controls, and auditability.

Example non-functional requirements

• Production deployment artifacts shall be signed using approved signing keys before promotion to production artifact repositories.

• Validation method: Validate by inspecting artifact signatures, signing pipeline logs, key ownership records, and artifact repository metadata.

• Example validation evidence: Signed artifact record, signing logs, key management evidence, artifact repository metadata, and release approval.

• Deployment platforms shall reject unsigned or unverified production artifacts when signature verification is required by the release policy.

• Validation method: Validate through negative deployment testing using unsigned or invalidly signed artifacts and confirm rejection behavior and logging.

• Example validation evidence: Negative deployment test report, admission-control logs, policy configuration, rejected artifact record, and platform approval.

Related stakeholders

Typical stakeholders include security teams, DevSecOps teams, platform engineers, release managers, operations teams, and audit stakeholders.

Related lifecycle phases

Artifact signing NFRs are defined during release architecture and platform governance; validated during pipeline execution, artifact promotion, deployment testing, production release, and recurring control review.

Best Practice: Define container image and deployment package security non-functional requirements

Description

Container image and deployment package security NFRs define how images, base layers, operating system packages, runtime libraries, manifests, Helm charts, installers, and deployment packages are built, scanned, hardened, stored, promoted, and deployed. They should include base image approval, vulnerability scanning, minimal package footprint, configuration hardening, and registry controls.

Benefits

These requirements reduce the risk that vulnerable, oversized, misconfigured, or untrusted deployment artifacts reach production environments.

Example non-functional requirements

• Production container images shall be built from approved base images and scanned for vulnerabilities before deployment.

• Validation method: Validate through image build records, base image approval evidence, vulnerability scan results, and deployment gate logs.

• Example validation evidence: Image scan report, base image approval, build logs, registry metadata, deployment gate evidence, and release approval.

• Container images shall not run as root unless explicitly approved through a documented exception.

• Validation method: Validate through image configuration scanning, runtime policy checks, and exception review for any approved root execution.

• Example validation evidence: Image configuration scan, admission policy results, exception approval, runtime evidence, and security review record.

Related stakeholders

Typical stakeholders include platform engineers, DevSecOps teams, developers, security teams, release managers, operations teams, and cloud teams.

Related lifecycle phases

Container and package security NFRs are defined during platform design and release standards; validated during build, scan, promotion, deployment testing, production release, and recurring image review.

Best Practice: Define Infrastructure as Code (IaC) security validation non-functional requirements

Description

Infrastructure as Code (IaC) security validation NFRs define how infrastructure definitions, templates, policies, modules, and configuration-as-code are reviewed, scanned, tested, approved, and monitored for security and compliance before deployment. They should address policy-as-code, least privilege, network exposure, encryption, logging, drift, and environment differences.

Benefits

IaC validation requirements reduce the risk of insecure cloud or infrastructure configuration being repeatedly deployed through automation. They also make infrastructure control evidence repeatable and traceable.

Example non-functional requirements

• Infrastructure as Code used for production environments shall pass approved security policy checks before deployment.

• Validation method: Validate through IaC scanning and policy-as-code enforcement in the CI/CD pipeline before infrastructure promotion.

• Example validation evidence: IaC scan results, policy-as-code report, pipeline logs, deployment approval, and exception records.

• Production infrastructure drift from approved IaC definitions shall be detected, reported, and remediated or risk-accepted within approved timelines.

• Validation method: Validate through drift detection reports, remediation tickets, configuration review, and exception approvals.

• Example validation evidence: Drift detection report, remediation record, configuration baseline, exception approval, and operations review evidence.

Related stakeholders

Typical stakeholders include platform engineers, cloud teams, infrastructure teams, DevSecOps teams, security teams, operations teams, and audit stakeholders.

Related lifecycle phases

IaC security validation NFRs are defined during platform architecture and infrastructure automation design; validated during CI/CD execution, environment provisioning, release readiness, drift review, and audit review.

Best Practice: Define vendor and third-party software attestation non-functional requirements

Description

Vendor and third-party software attestation NFRs define what evidence vendors, suppliers, SaaS providers, contractors, and third-party software producers must provide to demonstrate that their software, development practices, dependencies, security controls, and release processes satisfy required expectations.

Benefits

Third-party attestation requirements improve supplier accountability and help organizations manage risks that are outside the direct control of internal development teams.

Example non-functional requirements

• Vendor-provided software used in production shall have documented security, privacy, and software supply chain evidence appropriate to its risk classification before onboarding.

• Validation method: Validate through vendor risk review, supplier questionnaire review, contract control review, and approval of required evidence before production use.

• Example validation evidence: Vendor risk assessment, supplier questionnaire, contract control mapping, attestation record, and approval decision.

• Critical vendor software updates shall include release notes, vulnerability disclosure information, and applicable security attestation or equivalent evidence before deployment.

• Validation method: Validate through vendor release package review and change approval review before production deployment.

• Example validation evidence: Vendor release notes, vulnerability disclosure record, attestation evidence, change approval, and deployment record.

Related stakeholders

Typical stakeholders include vendor management, procurement, legal, security teams, privacy teams, compliance teams, product owners, platform owners, and audit stakeholders.

Related lifecycle phases

Vendor attestation NFRs are defined during vendor selection, contract negotiation, procurement, solution design, and onboarding; validated during vendor review, change review, release approval, renewal, and audit review.

Best Practice: Define vulnerability scanning, remediation, and exception non-functional requirements

Description

Software supply chain vulnerability scanning, remediation, and exception NFRs define how code, dependencies, containers, artifacts, IaC, and third-party components are scanned, prioritized, remediated, retested, excepted, and reported. They should specify blocking thresholds, remediation timelines, risk acceptance authority, and evidence retention.

Benefits

These requirements prevent vulnerable software supply chain components from silently moving into production and create a governance path for known risk.

Example non-functional requirements

• Production releases shall block promotion when software supply chain scans identify unapproved critical vulnerabilities in dependencies, containers, artifacts, or IaC.

• Validation method: Validate through pipeline scan configuration review and test releases containing known blocking findings to verify promotion blocking behavior.

• Example validation evidence: Pipeline configuration, scan report, blocked release evidence, remediation ticket, exception register, and release approval record.

• Approved exceptions for unresolved supply chain findings shall include risk owner, compensating control, expiration date, and retest expectation.

• Validation method: Validate by reviewing the exception register and sampling exception records for required fields and approval authority.

• Example validation evidence: Exception register, risk acceptance record, compensating control evidence, retest plan, and governance approval.

Related stakeholders

Typical stakeholders include security teams, DevSecOps teams, developers, platform teams, release managers, risk stakeholders, and compliance stakeholders.

Related lifecycle phases

Supply chain vulnerability NFRs are defined during release governance and DevSecOps design; validated during CI/CD scanning, release readiness, vulnerability review, exception review, and audit review.

Best Practice: Define software supply chain validation and evidence non-functional requirements

Description

Software supply chain validation and evidence NFRs define the evidence required to prove that source, dependency, build, artifact, container, IaC, vendor, scanning, remediation, and release-control requirements have been satisfied. Evidence should be retained, traceable, and available for security, audit, incident response, and governance review.

Benefits

Clear validation evidence makes software supply chain security auditable and repeatable. It also supports faster incident response when a component, build, package, vendor, or artifact must be investigated.

Example non-functional requirements

• Each production release shall retain software supply chain evidence that includes source traceability, dependency scan results, SBOM, build record, artifact metadata, and release approval.

• Validation method: Validate through release evidence review by sampling production releases and confirming that each required evidence type exists and maps to the released artifact.

• Example validation evidence: Release evidence package, SBOM, build logs, scan reports, artifact metadata, approval record, and traceability matrix.

• Software supply chain validation evidence shall be available for audit, vulnerability response, and incident review within the approved evidence retrieval timeframe.

• Validation method: Validate by performing evidence retrieval tests for sampled releases and measuring retrieval time and completeness.

• Example validation evidence: Evidence retrieval test record, sampled release evidence, access logs, audit notes, and improvement actions.

Related stakeholders

Typical stakeholders include DevSecOps teams, security teams, release managers, developers, platform teams, risk stakeholders, compliance stakeholders, and audit stakeholders.

Related lifecycle phases

Supply chain evidence NFRs are defined during release governance and evidence management design; validated during release readiness, recurring control review, audit review, incident response, and vulnerability response.