Summary: OpenSSF’s guidance on writing the standing instructions you give a coding assistant — the CLAUDE.md / .cursor/rules file as a security control. Includes a counter-intuitive finding: don’t tell the model it’s a security expert.
Sources: raw/Supply-chain-attacks/Security-Focused Guide for AI Code Assistant Instructions.md (OpenSSF Best Practices WG); 4 Best Practices for AI Code Security...md (StackHawk)
Last updated: 2026-07-29
OpenSSF (Linux Foundation) is vendor-neutral, and this is the most implementable artifact in the last two ingests: a copy-pasteable instruction block, with citations for each recommendation.
The premise
Standing instructions to a coding assistant are a security control, and they should be written like one. Crucially, OpenSSF warns against copying the whole thing:
“In most cases you should extract from this sample… If you copy and paste irrelevant parts, the AI is more likely to generate extraneous or even incorrect code as it attempts to compensate for attacks that can’t happen.”
Instruction bloat is itself a failure mode. Tell the model about threats it does not face and it will write defences you did not want.
The principle categories
- Input validation & output encoding — “treat all external inputs as untrusted”; parameterized queries; escape before rendering
- Authentication, authorization & secrets — never hard-code credentials; use vaults or environment variables; constant-time comparison “when timing differences could leak sensitive information, such as when comparing session identifiers, API keys, authentication tokens, password hashes, or nonces”
- Error handling & logging — generic user-facing errors, detail server-side only; avoid logging PII or secrets
- Secure defaults — HTTPS by default, strong algorithms, insecure protocols disabled, least privilege
- Testing for security — “generate unit tests for security-critical functions (including negative tests to ensure the code fails safely)”
- Data protection — minimisation, encryption at rest and in transit, anonymisation
Supply chain instructions
The section most relevant to this collection:
- Safe dependency selection — “Use popular, community-trusted libraries… Do not add dependencies that may be malicious or hallucinated.”
- Use package managers and lock versions — “Always use the official package manager… rather than copying code snippets”
- Stay updated — prefer latest stable, update regularly
- Generate an SBOM — SPDX or CycloneDX; in-toto attestations for build provenance
- Integrity verification — checksum or signature validation for external resources
On slopsquatting, OpenSSF adds a detail the other sources miss: “AI tools can often self-identify these names if asked to do so.” The model that hallucinated the package can frequently flag it on a second pass. That is a cheap, immediately deployable check.
A citation discrepancy worth noting
OpenSSF states “one study found 19.7% proposed packages did not exist,” citing Spracklen et al. — the same study Orca cites for 5.2% (commercial models) and 21.7% (open-source models).
These are different slices of one dataset, not conflicting findings; 19.7% is plausibly an aggregate or a different cut. But anyone quoting a single slopsquatting number should say which population it describes. Neither source in the vault reproduces the paper directly.
The finding that cuts against common practice
“We are not currently recommending in the general case that the AI be told to respond from a particular viewpoint (e.g., a role or persona)… An example would be ‘Act as a software security expert.’ Some experiments found that telling the system it is an expert often makes it perform poorly or worse on these tasks.”
Two reasons this matters:
- Persona priming is near-universal advice in prompt-engineering guidance. OpenSSF says the evidence does not support it for security tasks.
- It is the defensive mirror of PITAX T01 Act as Interpreter and the persona-modulation family, where role assignment is used offensively to substitute a syntactic frame for a policy one. The same lever that helps an attacker does not reliably help a defender.
OpenSSF flags this as provisional and invites further experimentation.
Self-review as a step
The recommended follow-ups after generation:
“Review your previous answer and find problems with your answer.” “Based on the problems you found, improve your answer.”
And for targeted checks: “Analyze (specific area of code) to determine if it has (kind of vulnerability)… Justify your answer with specific evidence.”
The instruction block also asks the model to “run or simulate the use of tools like CodeQL, Bandit, Semgrep, or OWASP Dependency-Check… Repeat this process until the code passes all simulated scans.”
Treat simulated scanning as a prompt for the model to reconsider, not as a substitute for running the tools. The Stanford study is the reason for that caution — see do-users-write-insecure-code, where confidence rose faster than security.
Project-specific rules
StackHawk’s contribution is granularity: rules files scoped per project and per domain, with worked examples for healthcare security requirements and financial security requirements, plus Cursor-specific setup. Its structure — code security standards, dependency management, code review requirements, error handling — is a reasonable skeleton.
The general point: a rules file that says “be secure” is inert. One that says “this is a HIPAA-regulated service; never log PHI; all endpoints require role checks” changes output.
The uncomfortable part
This entire control class lives in files like CLAUDE.md, .cursor/rules and copilot-instructions — which is precisely the target of PITAX T46 Agent Instruction-File Injection, hiding instructions “often via invisible Unicode, in repository configuration the coding agent automatically trusts.”
Your security instructions and an attacker’s backdoor occupy the same file, with the same trust level. Instruction files therefore need integrity protection — review on change, signed commits, and treating edits to them as security-relevant. None of the sources here say so; the connection comes from PITAX.