Yes. Storybook-style workflows should be separated from privileged build and deployment paths so a compromised story file cannot access secrets or production credentials. The comparison is not between tools, but between low-trust development output and high-trust release execution. When those are mixed, one injected file can become a supply-chain incident.
Why this separation matters
Documentation workflows belong in a lower-trust zone than production build and deployment paths. Story files, preview content, and component docs are useful for developer productivity, but they should not inherit the same permissions as release pipelines. Once documentation and production execution share trust boundaries, an attacker only needs one writable doc path to reach secrets, tokens, or deployment credentials.
The practical issue is not whether the documentation tool is “safe” in isolation. It is whether its execution context can reach privileged build steps, cloud credentials, or release artifacts. If a docs workflow can read the same environment variables, mounted secrets, or CI permissions as the production pipeline, then a compromise in a non-release file can become an integrity failure for the software supply chain.
That is why teams should treat documentation as publishable output, not as an authority-bearing part of the release path. The stronger the coupling between docs and deploy, the easier it is for an injected Markdown file, storybook story, or preview asset to alter build behavior, exfiltrate secret material, or trigger unintended actions during packaging.
How the attack path usually appears
Most failures start with over-privileged build jobs, shared runners, or mixed-purpose CI configurations. A documentation task that only needs static rendering may still be granted repository secrets, cloud access, artifact signing privileges, or access to production variables. That creates an unnecessary bridge between low-trust content and high-trust execution.
A common weakness is assuming that “read-only” documentation content cannot do damage. In practice, modern build systems often evaluate templates, preprocessors, plugins, import graphs, or helper scripts. If any of those steps execute in the same trust domain as the release pipeline, malicious content can shift from passive text into active code with access to sensitive context.
Another recurring failure mode is permission reuse across environments. When docs, tests, and release jobs share the same service principal or token scope, defenders lose the ability to say which workflow was allowed to do what. Separation by role, environment, and secret set reduces blast radius and makes compromise easier to contain.
What good separation looks like
Good practice is to render documentation in a restricted build lane with no production credentials, no signing keys, and no ability to publish release artifacts. The docs pipeline should have only the permissions needed to generate previews or static output, while the production pipeline should be reachable only through a separate, tightly controlled release path.
That control becomes much easier to sustain when least privilege is applied to build identities and when sensitive actions require explicit elevation rather than standing access. NHIMG’s Privileged Access Management Guide and Just-in-Time Access and Zero Standing Privilege Guide are useful references for structuring that separation.
For teams designing the trust model itself, it helps to align documentation, preview, and release permissions with explicit authorization rules rather than convenience-based sharing. The Authorisation Models Guide is a good fit when you need to decide which actions belong to which workflow, and Cloud PAM and CIEM Guide is especially relevant where build systems sit inside cloud control planes.
Risk and Threat Considerations
When documentation and production builds share permissions, the main risk is supply-chain compromise through a low-trust entry point. A malicious or injected story file can abuse build-time access to secrets, over-permissioned tokens, or deployment paths that were never intended to be reachable from documentation content.
Failure mechanism: A docs workflow executes with production-equivalent privileges, allowing untrusted content, templates, or plugins to reach secret material, modify artifacts, or trigger privileged release actions.
Impact: The result can be secret exposure, unauthorized deployments, tampered artifacts, or broader compromise of the build and release trust chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and SLSA set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Docs and build workflows should not share excessive privileges or release secrets. |
| NHI-07 — Long-Lived Secrets | Shared pipeline credentials and tokens increase blast radius in mixed-trust workflows. | |
| Recommendation — Right-size workflow permissions and remove standing access to production secrets. Rotate and shorten-lived credentials used by build and documentation jobs. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Separating docs from production builds is a least-privilege access decision. |
| IA-5 — Authenticator Management | Build and docs pipelines depend on secrets and tokens that need lifecycle control. | |
| SA-11 — Developer Testing and Evaluation | Untrusted docs content should be tested in a lower-trust lane before release. | |
| Recommendation — Limit each workflow to the minimum permissions needed for its role. Manage pipeline secrets with rotation, protection, and revocation controls. Run documentation content through isolated validation before production publication. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about separating access between low-trust docs and high-trust release paths. |
| Recommendation — Define and enforce separate access rules for documentation and production workflows. | ||
| SLSA | Supply-chain integrity | Mixed-trust build paths threaten artifact integrity and release provenance. |
| Recommendation — Isolate build steps so untrusted docs cannot alter release artifacts or provenance. | ||
Practitioner Guidance
What to prioritise: Separate the permissions first, then review the tooling. If the docs path can see production secrets, the issue is not cosmetic, it is an access-control defect. Treat that as a release risk, not just a documentation hygiene issue.
What to verify: Confirm that docs jobs use distinct identities, distinct secret sets, and distinct artifact destinations from production builds. Check runner scope, inherited environment variables, plugin execution, and any path that can turn preview content into code execution.
Common mistake: Teams often secure the repository but leave the pipeline shared. That leaves a gap where the content itself is reviewed, but the execution environment still has enough privilege to turn a small content compromise into a production incident.
Practitioner takeaway: The safe pattern is not “docs are harmless”, it is “docs are allowed to fail without touching release authority.” If a documentation workflow can influence production, it needs its own boundary, its own identity, and its own blast-radius limits.