Build a security glossary from the terms people actually stumble over, define each in one plain sentence, add a concrete example and a link to the page where the term matters, and give the glossary an owner. Keep it short. A glossary of 40 clear terms beats a catalog of 400.
Why a glossary pays off
Security language is a barrier. New engineers meet SBOM, CVSS, SAST, SCA, least privilege and zero trust in their first month. If nobody explains them, people either guess, avoid the topic or ask the same questions repeatedly. A glossary gives one agreed meaning, which also stops teams from using the same word for different things.
Choose terms from real confusion
Do not start from a standards document. Start from:
- Terms in scanner output and pull request checks.
- Words in your own policies and standards.
- Acronyms new hires ask about.
- Words that two teams use differently.
Aim for 30 to 50 terms at first.
The entry format
| Part | Example for the term "reachability" |
|---|---|
| Term | Reachability |
| Definition, one sentence | Whether your code can actually call the vulnerable part of a dependency. |
| Why it matters | A reachable flaw is more urgent than one in code that never runs. |
| Example | A library has a flaw in its XML parser, and your service never parses XML with it. |
| Related | Link to the triage FAQ and the exploitability page |
| Not to be confused with | Exposure, which is whether a service can be reached from outside |
The last row is often the most valuable. Many security mix ups come from near neighbors.
Writing rules
- Define in plain words, without using the term itself.
- Keep the definition to one or two sentences.
- Spell out acronyms on first use.
- Use the same name everywhere. If you call it a software bill of materials, do not switch to "dependency list" elsewhere.
- Say when a term means something specific in your company that differs from common usage.
Where to put it
Link terms from your docs automatically if your platform supports it, or at least from the first use on each page. Show the glossary in the knowledge base sidebar, and make each term its own page so search can find it. For the search side, see making docs findable.
Maintenance
- Assign an owner and review twice a year.
- Add a term whenever the same explanation is typed in chat twice.
- Remove terms for retired tools.
- Check the definitions against authoritative sources when terms are tied to a standard, since meanings can change.
Existing glossaries on specific topics can serve as a model, such as scanner terms explained.
Where Safeguard fits
Safeguard's free scan at gold.safeguard.sh/scan produces findings with terms such as dependency, vulnerability and reachability, which gives new engineers a real example to attach each glossary entry to.
Quick check
Should the glossary include every standard's vocabulary?
No. Include terms your engineers meet. Link out to the standard for the rest.
Who writes the definitions?
Security writes the first draft, and engineers review for clarity. If an engineer cannot paraphrase it, rewrite it.
Last reviewed: 19 October 2026.
