The standard for what counts as a legitimate source when deriving How to Harden guide content, and how each tier may be used. Every control, rationale claim, and hardening link in this repo traces to a source admitted under this taxonomy.
The bright line: a vendor's Trust Center, company "Security" marketing page, compliance-badge page, or "we take security seriously" whitepaper about the vendor's OWN infrastructure is never a hardening source. The test for any page: does it give an administrator configuration steps, settings, or auditable requirements for hardening the product? If it describes the vendor's certifications or internal practices instead, it fails.
Tier semantics: each tier is marked by what it may do — ORIGINATE a control (be the reason a control exists and the source of its steps), SET VALUES (determine the recommended setting), or CORROBORATE (supply rationale, incidents, and attack context).
May: ORIGINATE controls · authoritative on FACTS (whether a setting exists, its name, its default, its console path)
What qualifies: the vendor's own admin guides, security-configuration docs, hardening guides, API/CLI references, and security-relevant release notes — on the official vendor docs domain.
Role: the mandatory source class. Every control must trace to at least one Tier 1 citation proving the setting exists as described; every ClickOps step and console path is transcribed from Tier 1.
Built-in conflict of interest: vendor docs prove what EXISTS, but vendor-recommended values favor adoption and compatibility. On strictness questions, Tier 1 does not outrank Tier 2 (see Conflict Resolution).
Representative examples (what a Tier 1 hardening doc looks like in the wild — the vendor's own docs domain, admin-configuration content):
| Vendor | Domain | Example hardening guide |
|---|---|---|
| GitHub | docs.github.com | Security hardening for GitHub Actions |
| HashiCorp Vault | developer.hashicorp.com | Production Hardening |
| Google Workspace | knowledge.workspace.google.com | Security checklist for medium/large businesses |
| Zscaler | help.zscaler.com | ZIA Policy Leading Practices Guide — note: help.zscaler.com is a client-rendered SPA returning HTTP 200 for nonexistent paths; verify URLs via help.zscaler.com/sitemap.xml, never via HTTP status |
| Snowflake | docs.snowflake.com | Authentication policies |
| Ona | ona.com | Guardrails overview |
Never qualifies: trust.vendor.com, vendor.com/security marketing pages, SOC 2 attestation pages, whitepapers about the vendor's own datacenters.
May: ORIGINATE controls · authoritative on VALUES (what to set)
Standing list:
| Source name | Source domain | Example hardening guide | Use for |
|---|---|---|---|
| CIS Benchmarks | cisecurity.org | CIS Microsoft 365 Foundations Benchmark | Per-product numbered baselines. Numbering shifts between major versions — verify IDs against the current release or map by control name with a version note |
| DISA STIGs | cyber.mil | Kubernetes STIG V2R5 (direct download) | The strictest per-product baselines; L3 targets and compliance tables — note: the public.cyber.mil/stigs/downloads index is a JS-only SPA returning an empty shell to fetchers, cite direct dl.dod.cyber.mil artifact URLs instead; do NOT use dl.cyber.mil (no dod) — that's an unrelated CAC-gated login portal; STIG version numbers (V2R5 etc.) churn, reverify the current revision before citing |
| CISA SCuBA | github.com/cisagov | ScubaGear (M365/Entra baselines) · ScubaGoggles (Google Workspace) | Machine-checkable policy IDs (GWS., MS.), preferred for compliance tables; also Binding Operational Directives and the KEV catalog |
| NSA CSI | nsa.gov / media.defense.gov | NSA/CISA Kubernetes Hardening Guidance v1.2 | Product-specific, configuration-prescriptive government guidance — media.defense.gov blocks fetchers/curl (403 even with a browser UA); verify via real-browser check per Verification Rule 1. This specific document is formally a Cybersecurity Technical Report (CTR), not literally labeled "CSI" |
| ACSC | cyber.gov.au | Essential Eight Maturity Model | Only where it publishes explicit control values; otherwise Tier 2b — cyber.gov.au hangs for automated fetchers, verify via real-browser check; the URL path has moved from the old /resources-business-and-government/ structure |
Role: set the recommended values, seed compliance mappings, and legitimately originate controls the vendor under-documents.
Rows whose example is in italics are described, not a session-verified URL — the authoring agent must fetch-verify a current URL from that domain (Verification Rule 1) before citing.
May: CORROBORATE and supply compliance mappings · may NOT originate a configuration step
Standing list:
| Source name | Source domain | Example framework/guide | Use for |
|---|---|---|---|
| NIST | csrc.nist.gov | SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations | Control-family mappings and rationale |
| CSA | cloudsecurityalliance.org | Cloud Controls Matrix (CCM) | Cloud/SaaS control mapping |
| ENISA | enisa.europa.eu | ENISA Threat Landscape 2025 | Rationale, EU context |
| BSI | bsi.bund.de | IT-Grundschutz-Kompendium Bausteine (Edition 2023) | Control catalog (DE); English tree 404s, use the DE path — module PDFs need ?__blob=publicationFile appended |
| SANS | sans.org | Practical MFA for the Enterprise: Enforcing Strong Authentication for Non-Human Identities | Rationale; occasional concrete steps (this one: empirical 21k-account Entra ID tenant study with a 3-phase remediation plan) |
| OWASP | owasp.org | OWASP Top 10 for LLM Applications · ASVS | Application-layer security (in lane); out of lane for SaaS tenant-admin toggles |
Role: control-family catalogs and abstractions by design; they justify and map controls but always need a Tier 1/2 source to instantiate an actual setting. Italic examples are described, not session-verified URLs — fetch-verify before citing.
May: CORROBORATE always · ORIGINATE only where no Tier 2 baseline covers the surface, and only after Tier 1 cross-verification
Admission criteria (all three): (1) demonstrated ORIGINAL product-specific research — a novel misconfiguration, attack chain, or detection they built; not vendor size, not content marketing; (2) named authors — an individual byline, or a named standing research team the organization consistently credits (e.g. "Unit 42", not an anonymous/unattributed post); (3) technical reproducibility — claims reference actual admin-console settings or API endpoints.
Standing list (extend via the criteria, not vibes):
Italic examples are described, not session-verified URLs — fetch-verify a current URL before citing.
Where Tier 3 leads: for new attack surfaces with no CIS/STIG/SCuBA coverage yet (AI SaaS: Claude, ChatGPT Enterprise, Copilot-class products), Tier 3 is often the only source with real content — it may originate controls there, flagged "no benchmark equivalent yet", and every step still cross-verified against the vendor's real admin UI/API (Tier 1) before shipping. A Tier 3 claim alone never ships unverified.
May: CORROBORATE and enrich · originate only with explicit Tier 1 verification
Admission criteria: named researcher with verifiable identity and track record (CVE credits, vendor-acknowledged disclosures, recognized conference talks — Black Hat, DEF CON, BSides, fwd:cloudsec); technical specificity (exact settings, reproducible steps); published on an accountable venue. This is a class, not a fixed allowlist — admit per the criteria. Representative example:
| Source name | Source domain | Example research |
|---|---|---|
| Dirk-jan Mollema | dirkjanm.io | Obtaining Global Admin in every Entra ID tenant with Actor tokens (CVE-2025-55241) |
Never: anonymous blogs, aggregator/SEO content, citation-of-a-citation — always resolve to the primary source.
- Fetch or it didn't happen. Every cited URL must be fetched successfully in the working session. Hosts that block fetchers (403s, JS-only shells) get a real-browser check before citation. Unverifiable URL = not a source. Beware SPAs that return HTTP 200 for nonexistent pages (LastPass-style, and
squareup.com/help, which serves the support homepage for dead article slugs;docs.jfrog.comis a mixed case — it returns HTTP 200 with the "Welcome to JFrog Docs" homepage for some nonexistent paths while genuinely 404ing others, so a content check is mandatory there): confirm real content rendered, not a shell. Beware too of hosts that answer fetchers with an authentication wall rather than the article (support.zendesk.com/hcserves a customer sign-in page to automated fetchers): a citation there needs a real-browser check and an inline note. Where a help center sits behind a bot wall that blocks even a real-browser check (support.pendo.io/hcreturns HTTP 403 to fetchers), the underlying Zendesk help-center JSON API is the legitimate verification fallback — verify the article content there, then cite the human-readable/hc/URL with an inline note saying so. Beware finally of the inverse trap, where the failure rather than the success is the false signal:docs.cyberark.comreturns 404 to WebFetch for every path including the site root, while serving the real page to a browser-UA request — a fetcher-blocking pattern that mimics a dead link instead of the usual 403. A 404 from a documentation host that is plainly still in business is a verification failure, not a finding; re-check with a browser-UA fetch or a real browser before concluding a page is gone. Two further host notes:www.beyondtrust.comreturns HTTP 403 to all automated fetchers, sodocs.beyondtrust.com(which 404s honestly and renders real content) is the verifiable BeyondTrust surface; and for CVE records,nvd.nist.govis frequently unstable whilecve.orgis a JavaScript shell — the CVE Program's API athttps://cveawg.mitre.org/api/cve/{CVE-ID}is the reliable verification route and returns the authoritative CNA-assigned record. Some vendor doc hosts are split-access:doc.workday.comrenders/admin-guide/en-us/manage-workday/**to unauthenticated fetchers while/admin-guide/en-us/authentication-and-security/**returns HTTP 401 and the release center 302s to customer SSO — so a Workday claim is citable only if it lives in the reachable tree; the rest gets an inline "not re-verifiable" annotation rather than an asserted fact. For UKG,developer.ukg.comis the open Tier 1 surface;library.ukg.comserves PDF binaries,community.ukg.comis a Salesforce SPA shell that returns no article content, andwww.ukg.comreturns HTTP 403. Two further named traps:docs.oracle.com/en/cloud/saas/human-resources/**(and, most likely, sibling Fusion SaaS book trees) is a landing-shell trap — it returns HTTP 200 with an identical generic shell for both existent and nonexistent paths, so neither status code nor rendered content distinguishes a live doc from a dead one; verify Oracle Fusion SaaS documentation through the release readiness pages (docs.oracle.com/en/cloud/saas/readiness/) or a real browser, and never write release-pinned URLs blind. Andsupport.gusto.comreturns HTTP 403 to all automated fetchers, so citations there require a real-browser check and an inline note. Two hosts need method-level workarounds rather than a simple retry:help.sap.comserves a JavaScript shell to fetchers and never reachesdocument_idlein a real browser, so neither a plain fetch nor a standard browser-automation wait returns article text — verification there requires reading the rendered DOM directly (ajavascript_toolinnerTextread), with the site'shttp.svc/elasticsearch endpoint as the fetchable discovery fallback for locating the right page. Andhelp.rippling.comis a full customer login wall with no JSON-API fallback (unlike the Zendesk-backed hosts above, where the help-center API rescues verification) — it serves a sign-in page to every unauthenticated request, so it cannot be used as a source at all; Rippling claims must come fromdeveloper.rippling.comor be framed as capability-level with their non-documentation source named inline. Three further hosts named during the ADP, BambooHR, and SAP Concur currency passes:help.bamboohr.comis a Salesforce SPA that returns an identical ~573 KB body for every path, including article IDs that do not exist — neither status code nor response size distinguishes a live article from a dead one, so article existence there is simply not verifiable by fetch and BambooHR claims should be sourced fromdocumentation.bamboohr.com(which fetches cleanly, including.mdvariants andllms.txt) instead. For ADP,support.adp.com/netsecure/pages/pub/docs/is the real fetchable Tier 1 surface — it serves administrator PDFs (Security Management online help, registration best practices, administrator quick-reference cards) — whereasdevelopers.adp.comis a catch-all SPA with no server-rendered content. Andhelp.sap.comis a client-rendered SPA whose article bodies do not appear in the fetched HTML; its backing elasticsearch JSON API is the legitimate verification fallback — verify the article content there, then cite the canonical human-readablehelp.sap.com/docs/...URL. Further host behaviors from the Marketing, IT-Ops, and AI/IaC currency passes:help.openai.comandopenai.com/index/**return HTTP 403 to WebFetch but serve real rendered articles to a curl request with a Chrome user-agent — a UA-gated variant of the browser-check rule.experienceleague.adobe.comis a partial landing-shell trap, worse than a plain SPA: many paths render a plausible navigation shell so a fetch returns real-looking content while the requested article does not exist, though deep doc paths resolve properly — the gate there is confirming the specific claimed content appears, since neither status, size, nor "content came back" is sufficient.cisecurity.org/cis-benchmarksis a JS-only SPA returning an empty shell to fetchers, so CIS Benchmark existence checks need a real browser — never conclude "no benchmark exists" from a fetch.learn.jamf.comis likewise a JS shell; its canonical form is/r/en-US/{bundle}/{Page_Name}(older/bundle/.../page/*.htmlURLs 301 there), and content needs a browser pass. When a vendor's docs site is a JS shell, check for a first-party docs source repository: ServiceNow'sraw.githubusercontent.com/ServiceNow/ServiceNowDocs/{release}/markdown/**mirror fetches cleanly, carriescanonical_urlfrontmatter back to the shell site, and is still first-party Tier 1 — caveat that the release branch is in the path, so mirror URLs are release-pinned even when the canonical is not. Several hosts serve honest 404s, making absence evidentiary there (a negative result is citable):mailchimp.com/help,docs.workato.com,twilio.com/docs, and the Freshservice and PagerDuty support hosts.docs.workato.com,learn.chatgpt.com, anddevelopers.openai.comeach publish an.mdtwin of every page (/en/<path>.mdfor Workato) — the most reliable fetch surface on those hosts. For Zendesk-backed help centers reachable through a vanity domain (help.klaviyo.com): cite the vanity host, never the underlying*.zendesk.comorigin, and always include the article slug — the bare-ID form redirects but is unstable and gives no signal when an article is retitled.www.braze.comrefuses TCP connections from automated fetchers outright, so Braze verification needs a real browser. And the DISA STIG document index sits behind a DoD authentication wall — record STIG coverage as "unverifiable" rather than "no STIG exists." - Currency. Cite the canonical/current URL, not one that 301-redirects (redirects rot; vendors migrate doc hosts — e.g., Google's support.google.com/a → knowledge.workspace.google.com).
- Capability claims need Tier 1. "The vendor now supports X" must be shown in vendor docs, not inferred from a Tier 3 post; if a Tier 3 finding contradicts Tier 1, re-fetch Tier 1 — the docs may have changed.
- Cite specifically. Tier 2 citations carry benchmark name + version + recommendation ID; re-verify on each benchmark release.
Do not average. Tier 1 wins on FACTS; Tier 2 wins on VALUES.
- Strictness conflicts (e.g., Google recommends SPF
~all; CISA SCuBA requires-all): the strictest defensible position from a prescriptive source is the documented recommendation; the more permissive vendor position is retained as an explicitly labeled compatibility note with the risk delta explained — never suppressed, never silently averaged. - Value precedence when tiers disagree: Tier 2 (conflict-of-interest-free) > Tier 1 vendor recommendation > Tier 3 > Tier 4.
- Fact disputes (does the setting exist, what is it called, what is the default): Tier 1's current docs always win.
- Stale guide vs current source: the current verified source wins; correct the guide in place (update-hth-guide skill).
Tiers 1-2/2b are standing allowlists that rarely change. Tiers 3-4 are standing lists plus per-citation review against the admission criteria; prune quarterly for dead links, acquisitions, and quality drift.
Every Example column entry must be a real, specific, fetch-verified, currently-live URL — never an italicized "described, not verified" placeholder. The italic notation exists only as a mid-research scratch state while an authoring agent is actively fetch-verifying; it must never be the value in a committed version of this file. If you add or edit a standing-list row, fetch the URL yourself before writing it — a plausible-sounding link that hasn't actually been fetched this session is not a source (Verification Rule 1).
"Relevant" is broader than a literal "hardening guide." A source doesn't need a page titled "Hardening Guide" to qualify — any documentation that teaches prevention, detection, deception, remediation, or recovery techniques for a specific product or platform is in scope: first-party admin/config docs, benchmark bodies' control catalogs, threat-intel writeups, incident postmortems, and detection-engineering research all count. Tier 2b's role is corroborate-only, so a control-family mapping or framework catalog page is a legitimate example there even without step-by-step remediation instructions — it still needs to be a real, specific, fetched URL, not a homepage or generic index.
| Date | Changes |
|---|---|
| 2026-08-08 | Extended Verification Rule 1's SPA-trap sentence with named hosts found during the Square, Zendesk, and JFrog currency passes: squareup.com/help returns HTTP 200 with the support homepage for article slugs that no longer exist, support.zendesk.com/hc serves a customer sign-in wall to automated fetchers, and docs.jfrog.com inconsistently returns HTTP 200 with its docs homepage for some nonexistent paths while genuinely 404ing others — making a content check mandatory there. Added a further clause from the Pendo currency pass: support.pendo.io/hc returns HTTP 403 to automated fetchers, and the Zendesk help-center JSON API is the legitimate verification fallback for such hosts. Added two more from the Oracle HCM and Gusto currency passes: docs.oracle.com/en/cloud/saas/human-resources/** (and likely sibling Fusion SaaS book trees) is a landing-shell trap that returns HTTP 200 with an identical generic shell for both real and nonexistent paths — verify via the release readiness pages or a real browser, and never write release-pinned URLs blind; and support.gusto.com returns HTTP 403 to all automated fetchers, requiring a real-browser check and an inline note. Added split-access and surface notes from the Workday and UKG currency passes: doc.workday.com renders /admin-guide/en-us/manage-workday/** to fetchers but returns HTTP 401 on /admin-guide/en-us/authentication-and-security/**, with the release center 302ing to customer SSO — so a Workday claim is citable only from the reachable tree and the rest gets an inline "not re-verifiable" annotation; and for UKG, developer.ukg.com is the open Tier 1 surface while library.ukg.com serves PDF binaries, community.ukg.com is a Salesforce SPA shell, and www.ukg.com returns HTTP 403. Added two from the BeyondTrust currency pass: www.beyondtrust.com returns HTTP 403 to all automated fetchers while docs.beyondtrust.com is the open surface that 404s honestly and renders real content; and cveawg.mitre.org/api/cve/{CVE-ID} is the reliable CVE verification route, given nvd.nist.gov instability and cve.org being a JavaScript shell. Added the inverse trap from the CyberArk/Idira currency pass: docs.cyberark.com returns HTTP 404 to WebFetch for all paths including the site root while serving real content to browser-UA requests — a fetcher-blocking pattern that mimics a dead link rather than the usual 403, so a 404 from a plainly-live documentation host must be re-checked with a browser-UA fetch before being treated as link rot. Added three more from the ADP, BambooHR, and SAP Concur currency passes: help.bamboohr.com is a Salesforce SPA returning an identical ~573 KB body for every path including nonexistent article IDs, so article existence is unverifiable by status or size and BambooHR claims should be sourced from documentation.bamboohr.com instead; support.adp.com/netsecure/pages/pub/docs/ is ADP's real fetchable Tier 1 surface (administrator PDFs) while developers.adp.com is a catch-all SPA with no server-rendered content; and help.sap.com is a client-rendered SPA whose article bodies are absent from the fetched HTML, with its backing elasticsearch JSON API as the legitimate verification fallback before citing the canonical help.sap.com/docs/... URL. Sharpened the help.sap.com clause during the SAP SuccessFactors currency pass: the host serves a JS shell to fetchers and never reaches document_idle in a real browser, so a standard browser-automation wait returns nothing either — verification requires a direct rendered-DOM read (javascript_tool innerText), with the http.svc/elasticsearch endpoint as the fetchable discovery fallback for locating pages. Added help.rippling.com from the Rippling currency pass: a full customer login wall with no JSON-API fallback (unlike the Zendesk-backed hosts, where the help-center API rescues verification), so it is not citable at all — Rippling claims must come from developer.rippling.com, or be framed as capability-level with the non-documentation source named inline. Folded in the final-wave host notes: help.openai.com/openai.com/index are UA-gated (403 to WebFetch, real content to curl with a Chrome UA); experienceleague.adobe.com is a partial landing-shell trap requiring a specific-content check; cisecurity.org/cis-benchmarks and learn.jamf.com are JS shells needing real-browser checks (jamf canonical is the /r/en-US/ form); the ServiceNowDocs GitHub mirror is a fetchable first-party Tier 1 surface with canonical_url frontmatter (generalizable: JS-shell docs sites may have a first-party source repo), release-pinned by branch path; mailchimp.com/help, docs.workato.com, twilio.com/docs, and the Freshservice/PagerDuty support hosts serve honest 404s (absence is evidentiary); docs.workato.com/learn.chatgpt.com/developers.openai.com publish .md twins of every page; Zendesk-vanity hosts like help.klaviyo.com are cited by vanity domain with the slug included; www.braze.com refuses fetcher TCP connections; and the DISA STIG index is behind a DoD auth wall, so STIG coverage is recorded as unverifiable, never as absent. |
| 2026-08-08 | Added a verification caveat to the Tier 1 Zscaler row: help.zscaler.com is a client-rendered SPA that returns HTTP 200 for nonexistent paths, so link verification there must go through help.zscaler.com/sitemap.xml rather than HTTP status. |
| 2026-08-08 | Replaced all remaining italicized placeholder example URLs (Tier 2: DISA STIGs, NSA CSI, ACSC; Tier 3: Obsidian Security, Unit 42, Rapid7 Research, Praetorian, AppOmni, GitGuardian, Mitiga, Varonis Threat Labs) with real fetch-verified URLs. Relaxed Tier 3 admission criterion 2 to accept a named standing research team (not just an individual byline) per principal decision — Obsidian Security and Unit 42 both publish substantive, technically-reproducible, product-specific research under consistent team bylines. |
| 2026-08-08 | Converted the Tier 1 (examples), Tier 2, Tier 2b, Tier 3, and Tier 4 source lists into tables carrying Source Name + Source Domain + Example Hardening Guide, so authoring agents search by domain and know what a real hardening guide from each source looks like (verified URLs where available this session; italic = describe-then-fetch-verify). Added Pluto Security (pluto.security) to the Tier 3 standing list with its verified Claude Tag hardening guide as the example. |
| 2026-08-08 | Council-refined revision: Tier 2/2b split (prescriptive bodies vs framework catalogs), originate/values/corroborate semantics per tier, facts-vs-values conflict rule with strictest-defensible precedence, Tier 3 elevation for un-benchmarked surfaces with mandatory Tier 1 cross-verification, maintenance cadence. Two council seats (formal semantics, provenance rigor) were synthesized conservatively — revisit if those areas prove contentious. |
| 2026-08-08 | Initial version — taxonomy formalized from the August 2026 full-repo audit (A–Z link audit, currency waves, trust-center purge). |