Security policy document describing supported versions, vulnerability reporting procedures, and responsible disclosure guidelines for a project.
SECURITY.md
SECURITY.md is a markdown file placed at the root, docs/, or .github/ folder of a code repository that documents a project’s security policy: which versions are supported, how to report a vulnerability, and what a reporter can expect in response. GitHub, GitLab, and other forges surface it automatically — GitHub links to it from a repository’s Security tab and prompts maintainers who haven’t added one. It is the source-code sibling of a hosted security.txt: a low-cost, discoverable answer to the question “who do I tell, and how?”
- Supported versions - A clear statement of which releases still receive security fixes, so reporters know what is in scope.
- Reporting channel - An email, form, or private advisory path for responsible disclosure instead of a public issue.
- Disclosure expectations - Response timelines, coordination, and any safe-harbor language for good-faith researchers.
- Native discoverability - Forges render and link the file, making the policy easy for humans and tools to find.
In API operations, a SECURITY.md in the provider’s public repositories is a concrete, machine-checkable signal that a real disclosure process exists behind the API. I have long recommended vulnerability disclosure as a core API building block, and the presence or absence of this file is one of the cheapest maturity signals to score across a catalog. As agents and automated scanners increasingly assess whether an API is safe to depend on, a published policy — in both SECURITY.md and security.txt form — becomes a fast proxy for operational seriousness about security.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
