# Vendor Guides and Standards Map

![Compliance and Assurance](/files/9g1IgyycH6AhMX64O7j5)

## Vendor Guides and Standards Map

> **Section focus:** connect generic standards to exact implementation behavior.\
> **Best use:** use this page after you know which framework matters, but before you start turning requirements into pipeline checks, platform baselines, and evidence.

### Why this page exists

A standard tells you **what outcome matters**. A vendor guide tells you **how a given product actually behaves**.

You usually need both.

A strong Product Security program should avoid two bad extremes:

* relying only on standards and ending up with abstract controls nobody can implement;
* relying only on vendor docs and losing the control objective, audit narrative, or risk context.

### Useful reference families

| Source family           | Best use in the knowledge base                                                                     |
| ----------------------- | -------------------------------------------------------------------------------------------------- |
| **OWASP**               | application, API, verification, cheat sheets, secure design patterns                               |
| **CIS Benchmarks**      | host, Docker, Kubernetes, and cloud configuration baselines                                        |
| **NIST / NSA / CISA**   | container, Kubernetes, SDLC, and hardening guidance with stronger government-style control framing |
| **Cloud vendor docs**   | exact implementation behavior and service-specific syntax                                          |
| **Project-native docs** | OPA, Kyverno, Harbor, GitLab, Trivy, Falco, Tetragon, and similar tooling detail                   |

### High-value mappings

#### Containers

* use **NIST SP 800-190** and Docker or Kubernetes hardening guidance for risk framing;
* use **CIS Docker** for daemon, host, image, and runtime baseline checks;
* use project docs for exact flag, config, and policy syntax.

#### Kubernetes

* use **NSA/CISA** hardening guidance for a structured cluster-hardening model across Pod security, network separation, RBAC, secrets, audit logging, and upgrades;
* use **CIS Kubernetes** benchmarks for implementation-oriented checks;
* use Kubernetes documentation for current feature behavior such as Pod Security Admission.

#### DevSecOps and delivery controls

* use **SSDF, SAMM, BSIMM, DAF, and DSOMM** for program structure and maturity framing;
* use platform-native docs for branch protection, approvals, runners, signing, and evidence capture;
* treat compliance as code wherever possible.

#### Browser and web-server controls

* use standards and cheat sheets to define **why** HSTS, CSP, CORS, and cookie posture matter;
* use **Apache**, **Nginx**, CDN, and gateway docs for the exact syntax and deployment order;
* keep browser behavior notes alongside the engineering page that owns the runtime behavior.

### Decision rule: which source wins?

| Question                                              | Better source                                          |
| ----------------------------------------------------- | ------------------------------------------------------ |
| What outcome is expected?                             | Standard / framework                                   |
| Which control family does this map to?                | Standard / framework                                   |
| Which team should own it?                             | Internal operating model plus framework                |
| What exact config flag or header syntax should I use? | Vendor or project docs                                 |
| How do I prove the control is active?                 | Platform evidence + release artifacts + runtime checks |

### Practical examples

#### Example 1 — secure Kubernetes admission

* **Framework layer:** CIS / NSA-CISA tells you admission and workload policy matter.
* **Implementation layer:** Kubernetes, Kyverno, or Gatekeeper docs tell you the actual policy language and rollout mechanics.
* **Evidence layer:** CI tests, admission audit logs, and cluster policy inventory prove the control is active.

#### Example 2 — secure web headers

* **Framework layer:** browser security guidance tells you why CSP, HSTS, X-Content-Type-Options, or cookie attributes reduce risk.
* **Implementation layer:** Apache or Nginx docs tell you where to place header directives and how inheritance behaves.
* **Evidence layer:** scanner output, browser DevTools, and deployed config snapshots prove the settings are live.

#### Example 3 — secure GitHub or GitLab delivery

* **Framework layer:** SSDF, SAMM, or DAF tells you secure build, review, secrets, and release evidence matter.
* **Implementation layer:** GitHub Actions or GitLab docs tell you how protected refs, approvals, environments, and signing actually work.
* **Evidence layer:** pipeline artifacts, approvals, attestations, and release evidence make the control reviewable.

### How to use this map

When updating any page in this knowledge base, ask:

1. what standard or guide frames the control objective?
2. what vendor or project doc gives the exact implementation?
3. what local decision or exception model is needed for delivery reality?
4. what evidence can we collect continuously instead of manually at audit time?

### Related pages

* [Compliance and Assurance](/metrics-audit-risk-evidence-and-compliance/index-1.md)
* [Cloud Security Frameworks and Standards — Practical Map](/metrics-audit-risk-evidence-and-compliance/index-1/cloud-security-frameworks-and-standards-practical-map.md)
* [U.S. Cybersecurity Laws and Sector Compliance — Quick Map](/metrics-audit-risk-evidence-and-compliance/index-1/us-cybersecurity-laws-and-sector-compliance-quick-map.md)
* [Web-Server Security Controls: HTTPS, CORS, CSP, and HSTS for Apache and Nginx](/application-security-and-secure-sdlc/index-2/web-server-security-headers-https-cors-csp-and-hsts-for-apache-and-nginx.md)
* [Kubernetes Security Tooling Map and Standards](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-tooling-map-and-standards.md)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/metrics-audit-risk-evidence-and-compliance/index-1/vendor-guides-and-standards-map.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.