Cybersecurity Standards Framework
Security claims are only worth what they can be checked against. Gracker finds the official reference behind each claim, confirms it is real, and puts it where it belongs:
- On pages you already have. Every citation graded for whether it is real, linked, live and on-topic
- On pages you still need. The exact reference your competitor is already citing
- On pages Gracker writes. Woven inline, never invented
Why this exists
Every security page makes claims:
- "Session tokens should rotate after login."
- "MFA prevents credential stuffing."
- "This flaw is being exploited right now."
Each one has an official source behind it: a published standard, a catalogued weakness, a documented attack technique. Someone at NIST or MITRE wrote it down and gave it an identifier.
Naming that identifier is the difference between a claim a reader can verify and one they take on faith. Answer engines treat it as a safety signal:
| Your page says | What the assistant does |
|---|---|
| "Follow industry best practices" | Skips it, because there is nothing to check |
"NIST SP 800-63B requires this", linked | Quotes it, because the claim can be verified |
Most security content lands in the first row, and not through carelessness:
- Finding the correct reference is expert work: the right CVE, the right weakness class, the publication that genuinely backs the claim.
- It costs a security engineer 20-40 minutes per article.
- So security content queues behind engineering capacity. And when it gets rushed, a wrong or invented citation ships, then sits for months in front of exactly the readers you most need to convince.
Gracker does the lookup, guarantees every identifier it returns is real, and takes the job off one reviewer's calendar.
How it works, in one example
You publish a page: "Does single sign-on reduce phishing attacks?"
Gracker reads it, recognises it discusses an authentication control and a named attack technique, searches the official catalogues, and comes back with three references:
| Reference | What it is | Why it fits |
|---|---|---|
SP 1800-13 | A NIST publication on mobile single sign-on | The standard that backs your SSO claims |
CAPEC-98 | MITRE's catalogue entry for phishing | The attack pattern the page describes |
T1550.004 | An ATT&CK technique: stealing web session cookies | The bypass the page should mention |
Your sentence goes from:
SSO reduces phishing risk.
to:
SSO reduces phishing risk, though session-cookie theft (T1550.004 (opens in a new tab)) remains a live bypass, which is why NIST SP 1800-13 pairs SSO with phishing-resistant authenticators.
Same claim. Now checkable.
The six identifier types
Three organisations publish the identifiers security professionals treat as authoritative, across six id spaces. Each owns a different kind of fact.
| Source | What it catalogues | Example |
|---|---|---|
| NIST | Published standards and guidance | SP 800-63B - digital identity requirements |
| MITRE - CVE | One specific flaw in one product | CVE-2023-44487 - the HTTP/2 Rapid Reset flaw |
| MITRE - CWE | A class of weakness | CWE-89 - SQL injection as a category |
| MITRE - ATT&CK | What attackers actually do | T1566 - phishing as a technique |
| MITRE - CAPEC | How an attack is mechanically carried out | CAPEC-66 - the SQL injection method |
| CISA | Flaws confirmed to be under active attack | The Known Exploited Vulnerabilities (KEV) catalogue |
These are not interchangeable, and reaching for the wrong one is a tell. An article about SQL injection as a concept should cite CWE-89, the weakness class. An article about one vendor's broken login should cite that vendor's CVE. A reader who knows the subject spots the difference immediately, and so does an assistant weighing whether to repeat you.
Gracker judges each id space separately, so what comes back is the kind of citation your content actually calls for, not whichever one happened to share a keyword with it.
What "verified" guarantees
An AI decides whether a category of source applies to a page, and it may put a candidate forward - a product name worth searching for, or an identifier it believes fits. What it cannot do is make one count. Every candidate is looked up first, and a plausible-looking CVE-2029-99999 fails that lookup and never reaches a suggestion.
The URL is held to the same standard as the id. Every link points at the authority's own record page, not a summary, a mirror, or a blog that once described it.
The result is that a fabricated citation isn't something you catch in review. It's something that cannot reach the page.
In Page Audit
Standards checking runs whenever you audit a page that reads as substantive content: an article, a comparison, or an FAQ. Pricing, careers and feature pages are skipped, correctly.
What gets checked
Each authority the page touches is checked four ways, and a claim of active exploitation is checked against CISA on top of that.
| What's checked | Weight | What it catches |
|---|---|---|
| Is the identifier real? | Critical | A mistyped or invented CVE- / SP 800- id |
| Is a claim of active exploitation true? | Critical | "Actively exploited" on a CVE that isn't on CISA's KEV list |
| Is the citation on-topic? | Warning | A real reference attached to the wrong claim |
| Is the source actually linked? | Notice | Writing "NIST" in a sentence is not citing NIST |
| Does the link still resolve? | Notice | A citation that rotted since publication |
How it scores
Twelve checks in total, and together they are your Trust Score, one of the four sub-scores behind Page Health.
Critical counts 5x, warning 2x, notice 1x, so an invented identifier costs far more than an unlinked mention. That ordering is deliberate: a missing hyperlink is untidy, a fake identifier is a credibility failure.
Checks that cannot apply are excluded from the maths entirely rather than counted against you.
When a page shows no score
A page with no security claims to check shows "Not a security topic" instead of a score. That is a verdict, not a gap. There was nothing for a catalogue to match against.
In Visibility Diagnosis
When Visibility Diagnosis works out why you aren't winning an AI answer, cybersecurity brands get references attached to the result.
Briefs and gap reports
The diagnosis hands back one of two things, and both arrive with references:
- a content brief. You have no page for this question, so here is what to write
- a gap report. You have a page, so here is what it is missing against the one beating you
Why a competitor's citation ranks first
This is the only place the engine reads a competitor's actual page. Every identifier sitting on it is pulled out and verified, and the ones that survive are ranked above everything else and labelled as competitor citations.
They answer a sharper question than what could I cite? They answer what is the page outranking me already citing?, which is a gap you can close on purpose rather than a research problem you have to open.
References the report's own fixes call for come next. Gracker's own search results come last.
In Content Generation
When Articles writes a piece for a cybersecurity brand, references are woven into the prose as real inline hyperlinks, each placed in the sentence that already discusses that idea, never collected into a list at the bottom.
What you can expect
- Citations sit inline, in the sentence that already discusses them, never collected into a "References" list at the bottom.
- Every link points at the official record page, so a reader can check the claim in one click.
- Nothing is said about a reference that wasn't verified - no severity scores, dates or product names appear unless they came from the source itself.
- Only vulnerabilities confirmed as actively exploited are described that way.
- The rest of your article is left alone. Structure, headings, brand mentions and existing links all stay as written.
If anything goes wrong along the way, your article is left exactly as it was rather than half-edited.
Articles generated from a diagnosis
How a reference is chosen
The three passes
Not required reading. It is here because it explains why the output can be trusted.
In Visibility Diagnosis, where a competitor's page is in front of us, pass 2 outranks pass 1: if the reading pass says "no MITRE citation needed" while a real, verified CVE sits on the competitor's page, the evidence wins. Judgment can miss things. A confirmed identifier cannot be argued with.
Where each type comes from
| Type | How it's found |
|---|---|
| CVE | Live keyword search of the National Vulnerability Database, ranked by how many of your topic's search terms it matched, then severity, then recency |
| CWE | Followed from the chosen CVE's own weakness mapping: this flaw, then the weakness class behind it |
| CAPEC | Followed from that weakness's own attack-pattern mapping, plus an independent match against your page's meaning |
| ATT&CK | Matched by meaning against the full technique catalogue |
| NIST publication | Matched by meaning against the full publication catalogue (no live search API exists for these) |
| CISA KEV | Every CVE in play is checked against the actively-exploited catalogue in one batch, plus a direct search of it for your topic |
In Visibility Diagnosis, meaning-based matches must also clear a relevance floor: a weak match is dropped rather than shown, on the principle that a suggestion you never see costs you less than a wrong one you act on.
Why a reference was suggested
Every suggestion carries a plain reason, so you can judge it without opening anything.
| Reason shown | What it means |
|---|---|
| Cited by a competitor page | Found and verified on the page currently beating you |
| Called for by the fixes in this report | The diagnosis itself named this standard |
| Confirmed under active exploitation (CISA KEV) | This CVE is on CISA's Known Exploited Vulnerabilities catalogue |
| Most relevant CVE for this topic | Top NVD match for your subject |
| The underlying weakness behind this vulnerability | Followed from that CVE's own mapping |
| How this vulnerability is typically exploited | The attack pattern for that weakness |
| Related ATT&CK technique for this topic | Closest adversary technique |
| Most relevant NIST publication for this topic | Best publication match for your subject |
| Already cited on this page, just not linked | You had it right, so add the hyperlink |
How many you get
At most 2 NIST publications, up to 4 MITRE references (one CVE, one CWE, one CAPEC, one ATT&CK) and at most 2 CISA entries. Fewer whenever fewer genuinely fit. None at all is a legitimate answer, and a common one.
When nothing appears
Deliberately narrow. Security citations on non-security content are noise, and noise costs more credibility than silence.
| Condition | Effect |
|---|---|
| Brand not classified as cybersecurity | Nothing runs, anywhere |
| Page isn't an article, comparison or FAQ | No Trust Score on that page |
| No authority applies to the topic | "Not a security topic", a verdict rather than a gap |
| Nothing clears the relevance floor | No suggestion rather than a weak one |
| A catalogue can't be reached | The unconfirmed id is dropped, never shown unverified |
FAQ
How do I turn this on?
You don't. Gracker classifies each brand as cybersecurity or not the moment you add it, reading its name, domain, industry, description and the prompts you track. If the verdict is yes, Page Audit, Visibility Diagnosis and Articles all start including standards work on that brand's security content automatically. There is no setting to flip. See Brand Management.
What decides that my brand counts as cybersecurity?
Whether security is the core business, not whether security gets mentioned. Vendors of network, endpoint, cloud and application security, SIEM/SOAR/EDR/XDR/MDR, firewalls, threat intelligence, vulnerability management, penetration testing, IAM/PAM/SSO/MFA, zero-trust, DLP, encryption and PKI, security GRC, fraud and bot detection, DDoS protection and security awareness training all qualify. General IT and devops, observability, cloud hosting, data and analytics do not, even though all of them touch security. Payments is the one with a caveat: a fintech qualifies if the product itself is fraud or security, not if it merely moves money securely. If security is a feature of what you sell rather than the thing you sell, the answer is no.
My brand was classified wrong. Can that be corrected?
Yes. Contact support and it can be changed on our side. Classification runs once, when the brand is created, so the usual cause is a brand added before its positioning was filled in, or one whose description is vague about what it actually sells. A brand that couldn't be classified at all is left unclassified, and unclassified behaves exactly like "not cybersecurity": nothing runs.
My security page shows no Trust Score. Why?
Trust Score only appears where it is relevant: the page has to read as an article, comparison or FAQ, and it has to make security claims worth checking. Homepages never qualify, and Product or Service structured data outranks Article, so a comparison page carrying product schema is skipped. Adding JSON-LD declaring the page an Article is the usual fix. See Trust Score.
It says "Not a security topic" on a page that is obviously about security.
That verdict means no authority applies to the specific claims being made, which nearly always means the page stays at the category level - "misconfigurations", "weak permissions", "best practices" - without naming a specific weakness, technique, control or product. There is nothing concrete for a catalogue to match against. Naming the specific thing is both better writing and what makes a citation possible at all.
Can I publish these citations without checking them?
For existence and for the link, yes: every identifier was confirmed against the authority's own catalogue, and every URL points at that authority's record page. Relevance is a strong match rather than a guarantee, so whether a reference fits the argument you're making is still your call. That last judgment is deliberately left with you.
My Trust Score is low but every citation on the page is real. What's wrong?
Real is one of four checks. The others ask whether the source is actually hyperlinked, whether that link still resolves, and whether the citation is on-topic for the claim beside it. Naming NIST in a sentence with no link, or putting a real advisory next to an unrelated claim, both cost you - and a page can fail all three while every identifier on it is genuine.
Is a claim of active exploitation checked?
Yes, and it carries critical weight. If your page says a vulnerability is being exploited in the wild, that CVE is checked against CISA's Known Exploited Vulnerabilities catalogue. "Could be exploited" or "is exploitable" is a different claim and isn't judged this way - only an assertion of ongoing, real-world attack is.
Why two NIST publications instead of one?
So you have a choice. Topics often sit across two publications, and the second is sometimes the better fit for your particular angle. You're meant to pick one, not cite both.
Why did it suggest one vendor's CVE for my general article?
Usually because that CVE is the landmark case for the technique you're describing, or because a competitor cited it. If it genuinely doesn't fit, skip it - the CWE in the same set is normally the better citation for a conceptual piece, which is exactly why the two types are offered separately rather than as one "best" answer.
Will it duplicate a CVE that's already in my article?
No. If that CVE is on the verified list, the mention you already have becomes a single inline hyperlink rather than a second copy appearing further down. If it isn't on the list, it still gets linked to its official NVD record - but nothing is claimed about it, because its severity, date and affected product were never verified.
What about a CWE, CAPEC or ATT&CK id in my article that isn't on the verified list?
It stays exactly as you wrote it, as plain text. It won't be hyperlinked and nothing will be asserted about it. CVE is the exception only because a valid URL can be built from the id alone; the other catalogues have no such rule, so Gracker leaves them untouched rather than guessing at a link.
Will the article I generate use the same references I saw in the brief?
Yes, if you generate it from that diagnosis. The article inherits the diagnosis's verified references directly and skips re-discovery, so there's no drift between the brief you accepted and the piece that gets written. Generate an article outside a diagnosis and Gracker discovers references from the draft itself instead.
The diagnosis found no references. Will generation look again?
No. An empty result means the diagnosis looked and concluded nothing applies, and that verdict is respected - the article is written without references rather than second-guessed with a fresh search.
Will it add a "References" section to the bottom of my article?
No, and it's explicitly forbidden to. Every citation goes inline, in the sentence that already discusses that idea. A reference list at the bottom is easy to write and just as easy for a reader - and an answer engine - to ignore.
What happens if a lookup fails or a catalogue is unreachable?
It fails quiet, never loud. An identifier that can't be confirmed is dropped rather than shown unverified, a diagnosis carries on without its standards section, and an article that hits an error mid-pass ships with its original text intact. Nothing unverified is ever shown as a fallback.