Secure Coding Knowledge Base
Use this skill to make code work depend on official documentation instead of
assumptions, stale patterns, or unsourced community conventions. Maintain a
project-local persistent Reference Set and reuse it before consulting the
Internet.
Required Workflow
Execute this workflow before implementation, modification, review, or advice:
- Discover the repository architecture and relevant technologies.
- Locate the project Reference Set.
- Search the Reference Set before browsing.
- Fill only missing or stale guidance from official sources.
- Store new findings in the Reference Set.
- Apply the extracted guidance to the code change or review.
- Cite the Reference Set entries and official docs that affect the decision.
Do not skip discovery. Do not browse indiscriminately. Do not use community
sources when official documentation covers the subject.
Reference Set Location
Prefer a project-local Reference Set:
<repo>/.codex/reference-set/secure-coding.jsonl
Use the helper script when possible:
python3 /home/tintas/.codex/skills/secure-coding-knowledge-base/scripts/reference_set.py path
python3 /home/tintas/.codex/skills/secure-coding-knowledge-base/scripts/reference_set.py search "jwt issuer audience"
If the repository is not writable, report that the Reference Set could not be
updated and include the entry content that should be persisted.
Discovery
Inspect source and configuration files before deciding what documentation is
needed. Use fast local inspection such as rg --files, manifests, lockfiles,
Dockerfiles, CI files, IaC files, and service configuration. Read
references/discovery-and-extraction.md when architecture or technology
coverage is not obvious.
Identify:
- Architecture style: monolith, microservices, modular monolith,
event-driven, serverless, hexagonal, clean, onion, layered, CQRS, DDD, MVC,
MVVM, or feature-based.
- Languages, runtimes, package managers, frameworks, ORMs, databases, auth,
authorization, payments, messaging, queues, cache, cloud, containers, CI/CD,
IaC, and testing frameworks.
- Exact versions from lockfiles, manifests, runtime files, Docker images, SDK
versions, and provider configuration where available.
Source Priority
Before accessing the Internet:
- Search the Reference Set.
- Use complete matching entries immediately.
- Complete only the missing information for partial matches.
- Browse official documentation only when the Reference Set is missing,
stale, version-mismatched, or lacks the requested topic.
When browsing is needed, prefer sources in this order:
- Official language, framework, SDK, API, and vendor documentation.
- Official security guides.
- RFC specifications.
- OWASP documentation.
- CNCF documentation.
- Vendor knowledge bases.
- Community resources only when official sources do not cover the subject.
Store every new official finding in the Reference Set with source URL,
documentation section, topic, summary, security recommendations,
implementation recommendations, date indexed, last verification, and confidence
level. Read references/reference-set-schema.md before writing entries.
Refresh Rules
Refresh documentation only when:
- The Reference Set is missing.
- The technology version changes.
- The documentation is plausibly outdated.
- The requested subject has not been indexed.
- The existing entry has low confidence or does not cite an official URL.
Avoid duplicate entries. Update an existing entry when the same technology,
version, official URL, documentation section, and topic already exist.
Coding Rules
Every implementation or recommendation must follow:
- Official documentation for the detected versions.
- OWASP Top 10, OWASP ASVS, OWASP Proactive Controls, and OWASP API Security
Top 10 where relevant.
- Language and framework best practices.
- Vendor security guides.
- Secure-by-default principles.
If official guidance conflicts with current project style, explain the conflict
and choose the safer documented path unless the user explicitly asks otherwise.
Review Requirements
When reviewing code, verify insecure implementations, deprecated APIs,
deprecated security mechanisms, outdated recommendations, library misuse,
insecure defaults, missing validation, improper authorization, missing
authentication, weak cryptography, weak randomness, insecure token handling,
insecure payment handling, race conditions, concurrency issues, logic flaws,
edge cases, dead code, duplicated code, maintainability, scalability, and
architecture consistency.
Whenever a recommendation deviates from official documentation, cite the
relevant documentation section when possible.
Reporting
For implementation work, include a short note naming the Reference Set entries
or official docs that shaped the change.
For review work, lead with findings. For each finding include:
- File and line.
- Affected technology and version.
- Reference Set match or official source.
- Security or architecture impact.
- Recommended fix.
If no relevant Reference Set entries exist and browsing was not possible, state
that the recommendation is provisional and list the official docs that need to
be indexed.
1---2name: secure-coding-knowledge-base3description: Use this skill before implementing, modifying, reviewing, or suggesting code when the work should be grounded in official vendor documentation and secure coding guidance. It discovers the repository architecture and technologies, builds and reuses a persistent Reference Set of official documentation findings, and applies official docs, OWASP Top 10, OWASP ASVS, OWASP Proactive Controls, OWASP API Security Top 10, language best practices, framework best practices, vendor security guides, and secure-by-default principles. Trigger for code changes, architecture changes, dependency usage, authentication, authorization, cryptography, payments, API design, security reviews, hardening, validation, data handling, infrastructure, CI/CD, or any request where current official implementation guidance matters.4---56# Secure Coding Knowledge Base78Use this skill to make code work depend on official documentation instead of9assumptions, stale patterns, or unsourced community conventions. Maintain a10project-local persistent Reference Set and reuse it before consulting the11Internet.1213## Required Workflow1415Execute this workflow before implementation, modification, review, or advice:16171. Discover the repository architecture and relevant technologies.182. Locate the project Reference Set.193. Search the Reference Set before browsing.204. Fill only missing or stale guidance from official sources.215. Store new findings in the Reference Set.226. Apply the extracted guidance to the code change or review.237. Cite the Reference Set entries and official docs that affect the decision.2425Do not skip discovery. Do not browse indiscriminately. Do not use community26sources when official documentation covers the subject.2728## Reference Set Location2930Prefer a project-local Reference Set:3132```text33<repo>/.codex/reference-set/secure-coding.jsonl34```3536Use the helper script when possible:3738```bash39python3 /home/tintas/.codex/skills/secure-coding-knowledge-base/scripts/reference_set.py path40python3 /home/tintas/.codex/skills/secure-coding-knowledge-base/scripts/reference_set.py search "jwt issuer audience"41```4243If the repository is not writable, report that the Reference Set could not be44updated and include the entry content that should be persisted.4546## Discovery4748Inspect source and configuration files before deciding what documentation is49needed. Use fast local inspection such as `rg --files`, manifests, lockfiles,50Dockerfiles, CI files, IaC files, and service configuration. Read51`references/discovery-and-extraction.md` when architecture or technology52coverage is not obvious.5354Identify:5556- Architecture style: monolith, microservices, modular monolith,57 event-driven, serverless, hexagonal, clean, onion, layered, CQRS, DDD, MVC,58 MVVM, or feature-based.59- Languages, runtimes, package managers, frameworks, ORMs, databases, auth,60 authorization, payments, messaging, queues, cache, cloud, containers, CI/CD,61 IaC, and testing frameworks.62- Exact versions from lockfiles, manifests, runtime files, Docker images, SDK63 versions, and provider configuration where available.6465## Source Priority6667Before accessing the Internet:68691. Search the Reference Set.702. Use complete matching entries immediately.713. Complete only the missing information for partial matches.724. Browse official documentation only when the Reference Set is missing,73 stale, version-mismatched, or lacks the requested topic.7475When browsing is needed, prefer sources in this order:76771. Official language, framework, SDK, API, and vendor documentation.782. Official security guides.793. RFC specifications.804. OWASP documentation.815. CNCF documentation.826. Vendor knowledge bases.837. Community resources only when official sources do not cover the subject.8485Store every new official finding in the Reference Set with source URL,86documentation section, topic, summary, security recommendations,87implementation recommendations, date indexed, last verification, and confidence88level. Read `references/reference-set-schema.md` before writing entries.8990## Refresh Rules9192Refresh documentation only when:9394- The Reference Set is missing.95- The technology version changes.96- The documentation is plausibly outdated.97- The requested subject has not been indexed.98- The existing entry has low confidence or does not cite an official URL.99100Avoid duplicate entries. Update an existing entry when the same technology,101version, official URL, documentation section, and topic already exist.102103## Coding Rules104105Every implementation or recommendation must follow:106107- Official documentation for the detected versions.108- OWASP Top 10, OWASP ASVS, OWASP Proactive Controls, and OWASP API Security109 Top 10 where relevant.110- Language and framework best practices.111- Vendor security guides.112- Secure-by-default principles.113114If official guidance conflicts with current project style, explain the conflict115and choose the safer documented path unless the user explicitly asks otherwise.116117## Review Requirements118119When reviewing code, verify insecure implementations, deprecated APIs,120deprecated security mechanisms, outdated recommendations, library misuse,121insecure defaults, missing validation, improper authorization, missing122authentication, weak cryptography, weak randomness, insecure token handling,123insecure payment handling, race conditions, concurrency issues, logic flaws,124edge cases, dead code, duplicated code, maintainability, scalability, and125architecture consistency.126127Whenever a recommendation deviates from official documentation, cite the128relevant documentation section when possible.129130## Reporting131132For implementation work, include a short note naming the Reference Set entries133or official docs that shaped the change.134135For review work, lead with findings. For each finding include:136137- File and line.138- Affected technology and version.139- Reference Set match or official source.140- Security or architecture impact.141- Recommended fix.142143If no relevant Reference Set entries exist and browsing was not possible, state144that the recommendation is provisional and list the official docs that need to145be indexed.
Just1cup