# Secure Coding Knowledge Base > 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. - Skill: `just1cup/secure-coding-knowledge-base` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add just1cup/secure-coding-knowledge-base` - Raw SKILL.md: https://api.skillmd.com/api/skills/just1cup/secure-coding-knowledge-base/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: Just1cup (https://skillmd.com/u/just1cup) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/just1cup/secure-coding-knowledge-base --- # 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: 1. Discover the repository architecture and relevant technologies. 2. Locate the project Reference Set. 3. Search the Reference Set before browsing. 4. Fill only missing or stale guidance from official sources. 5. Store new findings in the Reference Set. 6. Apply the extracted guidance to the code change or review. 7. 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: ```text /.codex/reference-set/secure-coding.jsonl ``` Use the helper script when possible: ```bash 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: 1. Search the Reference Set. 2. Use complete matching entries immediately. 3. Complete only the missing information for partial matches. 4. 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: 1. Official language, framework, SDK, API, and vendor documentation. 2. Official security guides. 3. RFC specifications. 4. OWASP documentation. 5. CNCF documentation. 6. Vendor knowledge bases. 7. 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.