How can organisations reduce the risk of requirements for ASIC functionality being maliciously altered?

Control changes to ASIC requirements through strict change management, independent review, and traceability from requirement to implementation. Protect requirement repositories, limit write access, and require approval for any functional change. Regularly reconcile specifications against design artefacts so unauthorised or hidden capability changes are detected before fabrication.

How can organisations stop requirement tampering from becoming a fabrication flaw?

ASIC programmes are vulnerable when the specification layer is treated as a drafting space instead of a controlled security asset. The practical defence is to make requirement changes traceable, reviewable, and tightly permissioned, so a malicious edit cannot quietly move from text into silicon. That matters because once altered requirements are signed off, the defect is often baked into design and manufacturing.

What controls make requirement changes trustworthy?

Start with change control that treats requirement updates as security-relevant events, not routine documentation edits. Limit who can write to requirement repositories, require independent approval for any functional change, and keep an immutable history of who changed what, when, and why. Reconciliations between requirements, design artefacts, and implementation evidence help expose hidden or unauthorised capability shifts before release.

Good control also depends on clear separation between authorship and approval. The person proposing a change should not be the only reviewer, and specification baselines should be versioned so a later review can prove whether the design still matches the approved intent. Where requirements drive hardware features, cross-checking against test plans and verification traces gives you a second line of defence against stealthy modification.

How do teams detect maliciously altered specifications before release?

Detection works best when every requirement has a traceable path into design, validation, and release artefacts. If a specification changes without a corresponding change in design review, verification evidence, or sign-off records, that gap is a warning sign. Organisations should also watch for unusual repository activity, such as out-of-cycle edits, privilege escalation on the requirements platform, or silent changes to approval workflows.

Protecting the repository is as important as reviewing the content. Access logging, restricted write permissions, and periodic comparison of specification snapshots make it harder for an attacker or insider to alter a requirement and hide the trail. The objective is not merely to notice that a document changed, but to prove that the approved requirement set is the one being engineered and fabricated.

Risk and Threat Considerations

Requirement tampering is dangerous because it can redirect the final product without leaving an obvious security event at the point of fabrication. A subtle requirement change can introduce hidden functionality, weaken a control, or create a design that behaves differently from the approved safety or security intent.

Failure mechanism: The attacker or insider changes the specification upstream, then relies on poor traceability, weak review, or broad repository access so the altered requirement is accepted as legitimate and propagated into design and implementation.

Impact: The organisation may ship hardware that contains unauthorised behaviour, weaker assurances, or concealed capability changes, and the defect can be expensive or impossible to correct after production.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V13 — Configuration	Controlled requirement changes need protected baselines and change traceability.
Recommendation — Lock approved baselines and require review for any functional change.
NIST SP 800-53 Rev 5	CM-3 — Configuration Change Control	The question is about preventing unauthorized functional changes to controlled requirements.
	AC-6 — Least Privilege	Restricting write access to requirement repositories directly reduces tampering risk.
	AU-2 — Event Logging	Audit trails are needed to detect and investigate altered specifications.
Recommendation — Enforce formal approval for requirement changes before implementation. Limit repository write permissions to only essential approvers and editors. Log requirement edits and approvals so changes remain attributable.
SLSA	Supply Chain Integrity	Traceability from specification through implementation supports integrity of the build path.
Recommendation — Maintain provenance and traceability from requirements into implementation evidence.

Practitioner Guidance

What to verify: Confirm that every functional requirement has a named owner, approval record, and traceable link to the design and verification artefacts that implement it. If you cannot reconstruct the change path quickly, the control is not strong enough for a high-assurance ASIC process.

What good looks like: A requirement baseline is locked after approval, repository write access is tightly limited, and any deviation between the approved specification and downstream artefacts is flagged before tape-out.

Practitioner takeaway: Treat requirements integrity as part of product assurance, not document hygiene, because the cheapest time to catch malicious alteration is before the specification becomes hardware.