Trust Score

Trust Score checks whether your security content backs up its claims with real, working, relevant sources. Not just name-dropping NIST, MITRE, or CISA to sound credible.

Why it exists

• If your page says "this vulnerability is actively being exploited" or "this follows NIST guidelines," an AI assistant (and a human reader) has no way to know if that's true unless you point to something checkable.
• Pages that back their claims with real, verifiable sources get trusted - and cited - more.
• Pages that just throw around security buzzwords without backing them up don't.

Who this applies to

• Trust Score only shows up on cybersecurity content pages - a blog post, comparison, or FAQ that actually talks about vulnerabilities, attack techniques, or security frameworks.
• A pricing page or an about-us page will never be judged on this; there's nothing for it to apply to.
• If a page doesn't need any of NIST, MITRE, or CISA for its specific topic, the column shows "Not a security topic" instead of a score - that's not a missing result, it genuinely doesn't apply.

The three authorities - and what each actually is

NIST (National Institute of Standards and Technology):

• A science and standards body, not an enforcement agency.
• Publishes the frameworks and controls that security programs are built around.
• Examples: the Cybersecurity Framework, SP 800-53 (security controls), SP 800-63 (digital identity).

MITRE:

• Owns the catalogs that classify vulnerabilities and attacker behavior.
• CVE - a specific vulnerability instance.
• CWE - the weakness class behind it.
• ATT&CK - a real-world attacker technique.
• CAPEC - the attack pattern used.
• Four separate id spaces, checked independently. A page only needs to cite whichever one actually matches its topic - not all four.

CISA (Cybersecurity and Infrastructure Security Agency):

• An operational federal agency, not a standards body and not law enforcement. It coordinates with agencies like the FBI but doesn't investigate or prosecute.
• Its relevant piece here is the KEV catalog: vulnerabilities confirmed to be under active, real-world attack right now - not just theoretically exploitable.
• "This could be exploited" doesn't call for a CISA citation. "This is being actively exploited" does.

How GrackerAI decides your page needs a citation

An AI reads your page and judges, per authority, whether the topic actually calls for it. A page isn't checked against all three by default.

MITRE is triggered if the page names a specific vulnerability, weakness class, attacker technique, or attack pattern in real technical detail - a formal id isn't required ("SQL injection" or "Log4Shell" by name is enough). It then judges independently which id types actually fit:

• CVE - one specific vulnerability instance.
• CWE - a weakness class, like "buffer overflow" as a category.
• ATT&CK - a real-world adversary technique, like spearphishing.
• CAPEC - the attack pattern, how the attack is mechanically carried out.
• More than one can apply at once.

NIST is triggered when the page describes a specific security control, requirement, or process - concrete enough that a named framework or publication would plausibly back it. Examples: MFA requirements, an access-control model, incident-response steps, an encryption standard. Vague language like "security" or "best practices" with nothing concrete behind it doesn't trigger it.

CISA is triggered by either of two things:

• A claim of active, real-world exploitation happening right now.
• The page discussing CISA's own guidance, an advisory, a directive, or the KEV catalog by name.

What's checked

12 checks feed this score in total - four per authority (NIST, MITRE, CISA), each only counted when that authority actually applies to the page:

In plain terms, for each authority that applies to your page's topic, four things get checked in this order:

• Is the id real?
• Is it actually linked?
• Does that link still work?
• Is it actually about the right thing?

What moves the needle most

Not every issue counts the same:

• A fake or unverifiable id hurts the most. It's the difference between "backed by a real source" and "made something up."
• An unrelated citation is a real problem too, just a step down. The source is real, it just doesn't back the claim next to it. The fix isn't "add a link" - it's "cite something relevant," which is exactly what gets suggested.
• A missing or broken link is the smallest issue - usually a quick fix, not a credibility problem.

It tells you what to fix, not just what's wrong

• If a citation is missing, the audit looks up real, verified references you could add - not just flags the gap.
• Up to 2 suggestions for NIST, up to 2 for CISA, up to 4 for MITRE across its id types.
• Every suggestion links to the id's own correct page, not a generic catalog homepage.
• Already cited something real but forgot to link it? It tells you that directly, instead of suggesting something else.
• It never invents a source. No solid match means no suggestion.

How to raise it

• Double-check every id you cite is typed correctly and real.
• Make sure every source you name is an actual clickable link, not just plain text.
• Check your links still work - sources move or get taken down over time.
• Keep citations next to the specific claim they support, not floating somewhere unrelated on the page.
• If you're citing an actively-exploited vulnerability, link to a real per-CVE record (NVD or the CVE Program's own site) rather than just naming CISA in passing - that's what actually verifies the claim.

Next Steps