TL;DR: A build should receive only the authority required to produce its artifact. Production credentials needed by the running application should not automatically be available to dependency installation, asset compilation, test scripts, or cache generation. Inspect the actual build environment, output layers, logs, and deployment identities; then separate those boundaries deliberately. This October 28, 2026 review uses Railway's incident as context without claiming to reconstruct the provider's undisclosed exploit.
The inspection starts with a mundane question: why does a static frontend build have permission to query the production customer database? The answer is that the team placed every variable in one convenient configuration set. No build requirement was ever written. Access accumulated because the delivery system could provide it, and the distinction between a variable and a necessary authority disappeared.
Railway's variable documentation describes availability during builds and running deployments. Its incident report also discusses changes to its own build infrastructure. Those facts justify examining the customer's application boundaries, but they do not prove that a particular customer's build was compromised or identify the provider's complete root cause. The analysis below concerns controls an application owner can actually inspect. Railway variables Railway preliminary report
Room one contains the source and the installation scripts
An ordinary package installation can execute code, depending on the package manager, package contents, and chosen configuration. The build therefore needs a trust model for dependencies and scripts, rather than an assumption that downloading libraries is passive. This article does not prescribe disabling every installation script; some legitimate build processes require them.
The owner inventories which code executes before the application is packaged. That can include repository scripts, dependency lifecycle hooks, compiler plugins, asset generators, test helpers, and custom shell steps. Each participant can potentially interact with whatever the build environment makes available under its operating permissions.
The inventory attaches a task to each credential. A private-package reader may be needed to fetch a dependency. A production payment administrator usually is not. A database schema generator might require metadata, but that does not establish a need for unrestricted access to live customer records. The review asks which exact operation the build must perform.
This question often exposes an avoidable dependency. A team can generate a schema from a versioned file or a sanitized development database instead of connecting every build to production. That is a design alternative to evaluate, not a promise that every existing application can switch immediately. The owner compares the information actually required with the authority currently granted.
Room two contains the build's declared inputs
The build definition lists source revision, dependency lock information, compiler configuration, expected network sources, and any secret inputs. Listing a secret does not mean writing its value into provenance or a log. The useful record identifies the authority and its purpose, with sensitive material handled through the approved mechanism.
A fictional application, Cedar Catalog, needs one private-package credential to assemble its server image. It does not need its production database password until the server starts. Its original pipeline exposes both during every build. The inspection proposes removing the production password from the build environment while preserving the narrowly scoped package access.
The team validates that proposal by executing the relevant build in an approved environment without the production credential. A successful result is evidence that this tested build path did not require it. A failure identifies a dependency to investigate. The team does not immediately restore broad access merely because the first error message mentions a missing variable.
Sometimes initialization code reads a runtime secret during compilation even though the compiled result does not need it. Moving that initialization to runtime can remove the build dependency. The change must preserve application behavior and framework semantics; it should not replace a clear missing-secret error with a silent default that produces an incorrect artifact.
Room three contains the image layers
A container image is an artifact with a history and multiple storage surfaces. Removing a sensitive file in a later build step does not justify assuming that earlier layer content is absent from the distributed image or associated cache. The owner needs to understand the actual builder and output format rather than judging only the final visible filesystem.
Docker's build-secret documentation recommends dedicated secret or SSH mounts instead of passing sensitive values through build arguments or environment variables. Secret mounts expose data for a particular instruction under their documented behavior. This provides a more appropriate delivery mechanism for legitimate build-time authority, but it is not a promise that executing code cannot misuse the secret while it is available. Docker build secrets
Cedar's package-download step receives a restricted reader through the supported secret mechanism. The owner checks the command's configuration output, package-manager files, and generated artifact for accidental copies. A tool may write an authenticated registry URL into a config file or print a diagnostic that defeats the intended temporary delivery.
The acceptance question has two parts: was the secret available only where intended, and did any relevant output retain sensitive material? A successful image build answers neither automatically. The team examines the artifact and controlled build outputs without pasting real production secrets into a broad search tool merely to test whether searching works.
Room four contains the browser bundle
A server environment variable and a browser-delivered value have different confidentiality boundaries. Next.js documents that appropriately referenced variables prefixed with NEXT_PUBLIC_ are inlined into browser JavaScript at build time. A value delivered to users through a bundle should be treated as public regardless of how carefully the original environment variable was stored. Next.js environment variables
The owner distinguishes deliberately public configuration from server authority. A public analytics identifier or publishable integration key can be appropriate for a client bundle under its provider's design. A database credential or server API secret is a different object. Renaming a secret with a public prefix to fix a missing-value error changes where the secret goes, not whether the browser needs it.
Cedar's review includes generated assets, source maps where distributed, static page content, and client-visible error messages. These are outputs of the build that can carry information beyond the server. The owner checks what the application actually emits rather than assuming that a framework will prevent every developer-created disclosure path.
Build-time inlining also affects rotation. Replacing a server variable cannot erase a value already embedded in a previously distributed client artifact. If a server secret reached that artifact, the issuer must address its authority and the application must replace the affected output. Cache invalidation alone does not revoke a copied credential.
The review records framework version and compilation mode when a claim depends on them. A general article should not treat all static generation, server rendering, and client execution as equivalent. For this inspection, the controlling reference is the current Next.js App Router documentation checked on October 28, and the application's own build must be tested under its supported version.
Room five contains caches and diagnostics
A build cache can retain material from an intermediate operation even when the final artifact looks clean. Logs can retain command arguments, environment dumps, authenticated URLs, or responses containing sensitive data. The owner maps those destinations and their readers, retention periods, and cleanup procedures.
A cache is also an input to later builds. If its integrity is uncertain, a clean source revision can still produce an artifact influenced by old cached content. The team decides which caches are safe to reuse after the incident and which require a clean regeneration. Clearing every cache is not a substitute for understanding the trust path, but blindly reusing one can preserve an unwanted dependency.
Diagnostic practices matter during recovery. An engineer may temporarily print configuration to understand an authentication failure and then remove the print statement. The emitted value remains in the previous log. The response should address the affected credential and log artifact, not merely the source change that prevents future printing.
Cedar uses nonsecret configuration-presence checks and approved generation references for routine diagnostics. It tests a missing-secret failure without dumping the environment. Where a deeper investigation requires sensitive output, it uses a restricted process and retains the evidence under a clear lifecycle rather than exporting a whole runner workspace to a general team drive.
Room six contains the identity that deploys the artifact
The build identity and the deployment identity need not be the same. One may read package artifacts and write an image; another may promote a reviewed image to production. If a single token can change source, build arbitrary code, alter production configuration, and deploy it, compromise of one stage can cross several boundaries at once.
The design review asks what each identity can do and which event permits it to act. A build triggered by an unreviewed contribution should not inherit production authority simply because its workflow file resembles the main branch's workflow. The owner checks the CI provider's actual event and permission behavior instead of relying on an informal branch naming convention.
GitHub documents OpenID Connect as a way for supported workflows to obtain short-lived cloud access through an established trust relationship. The trust conditions and resulting cloud permissions remain essential. Short lifetime limits one dimension of exposure; it does not make an overly broad role or an untrusted workflow safe. GitHub Actions OIDC
Cedar's proposed trust policy identifies the approved repository and deployment context under the supported provider's semantics. The team tests both an allowed workflow and a deliberately disallowed context. The negative case matters: a token exchange that works from any repository would satisfy a happy-path test while violating the intended boundary.
The inspection also checks who can change those conditions. If an unreviewed source edit can alter the deployment workflow and obtain production authority, the nominal separation may be weaker than the diagram suggests. Control ownership includes the rules that issue authority, not only the secret values stored at the end.
Three redesigns solve different build requirements
The architecture discussion produces three options rather than a universal instruction to remove every secret.
| Design | Appropriate requirement | Boundary that still needs evidence |
|---|---|---|
| Secret-free compilation | Inputs can be obtained from approved public or prebuilt artifacts | Dependency integrity and reproducible input selection |
| Narrow build-time reader | A private package or source must be fetched | Scope, delivery mechanism, executing code, and output retention |
| Identity-mediated access | A supported workload can exchange identity for short-lived authority | Issuer trust conditions, permissions, lifetime, and auditability |
The first option is attractive where practical because it removes a distribution problem. It is not achieved by publishing private artifacts without approval. Cedar can mirror an approved dependency into a controlled artifact repository, but it still needs to protect the repository's contents and identify what version the build consumed.
The second option accepts that some sensitive authority is needed during the build. Its scope should match reading the required artifact rather than administering the registry or accessing unrelated repositories. A short-lived, read-only credential is useful only if the provider actually enforces those properties and the build's code cannot reach other unnecessarily exposed secrets.
The third option reduces long-lived copies but introduces a trust relationship that must be maintained. If the identity provider, repository policy, or claim interpretation changes, the deployment owner needs a review path. Replacing a static credential with a federation diagram does not eliminate ownership; it moves part of the responsibility to the token-issuance boundary.
Cedar chooses a narrow package reader for its current build and a separately authorized deployment identity. It records a future evaluation of federation because its target provider supports it, but does not delay a necessary removal of production database access until that larger migration is complete.
Inspect a failure path, not only a passing build
The team removes the package credential and observes the failure. The expected result is a clear inability to fetch the private dependency, with no fallback to an unapproved public package or a stale local copy. A pipeline that silently substitutes an artifact can produce a successful but untrustworthy build.
It then denies a production resource operation from the build context and verifies the intended lack of authority through an approved, harmless test. This is a scoped validation, not permission to probe unrelated customer resources. The test should answer whether the boundary is enforced without creating a new incident.
Another test introduces a controlled diagnostic error after the secret-consuming step. The owner inspects relevant logs and artifacts for the approved test marker rather than a real secret. That can reveal whether error handling serializes environment values or command configuration in a way the ordinary successful path never exposes.
The team also tests cache reuse. A build should not succeed only because an earlier authorized run left credentials or fetched content in an undocumented location. Where cached dependencies are legitimate inputs, their identity and integrity need a contract. An unexplained cache hit is a reason to investigate, not automatic proof that the build is secret-free.
The resulting evidence states which paths were exercised. It does not claim that a marker search proves all possible exfiltration absent. Runtime behavior, custom tools, encrypted outputs, and untested branches can escape a simple scan. The evidence combines configured authority, controlled execution, output review, and a bounded interpretation of each result.
Provenance must identify an artifact, not bless its contents
A signed statement about a build can help connect an artifact to source and process. It should not be mistaken for a statement that the source was harmless or the process had no access to secrets. SLSA's provenance model concerns verifiable information about where and how an artifact was produced, with specific tracks and properties. SLSA 1.2 provenance
Cedar records the produced image digest, source revision, reviewed build definition, and relevant builder identity. The deployment step consumes the identified artifact rather than rebuilding an ambiguously named latest tag. This reduces one uncertainty: the reviewed object and the promoted object can be compared directly.
The provenance review also asks what information is intentionally omitted. Raw secret values should not appear in an attestation to make a build fully specified. A reference to an approved secret generation or configuration policy may be appropriate under the team's design. Transparency about process should not become another credential-disclosure mechanism.
An artifact can have authentic provenance from an insufficiently protected builder. The review therefore assesses both the statement and the authority of the system that produced it. If the builder itself is under investigation, a valid signature from that builder is not a reason to ignore the investigation's scope.
The private registry is part of the authority boundary
The inspection initially focuses on runtime secrets and nearly overlooks the private registry credential. That credential may allow reading proprietary packages, publishing replacements, or changing repository settings, depending on its permissions. Calling it build-only can make it sound low consequence when its authority can affect every later deployment.
Cedar checks the reader's actual role and the identity used for publishing. The builder should not need the publisher's authority merely to install a package. If one credential serves both functions, the proposed separation reduces the consequence of a compromised install step without changing the package contents.
Package identity needs more than a familiar name. The build records the selected version and integrity information under the package manager's supported behavior. It also examines which registry resolves the package. A public package with a matching name is not necessarily an acceptable fallback for a private dependency, even when the build completes successfully.
Publication and promotion receive separate records. If a replacement image is rebuilt after a secret event, the team can identify which dependency artifacts were consumed and whether their publishing path was reviewed. A clean application commit cannot compensate for a dependency that was changed through an exposed publishing credential.
The registry's own audit and retention features may help investigate changes, but their availability must be checked. The team does not assume that every registry tier records the same actions for the same period. It preserves the source of each conclusion, especially when no historical publishing record is available and the investigation must rely on other artifact evidence.
These checks keep the design focused on authority rather than labels. A credential can be unnecessary in production yet highly consequential in a build. The right improvement is a purpose-specific permission and delivery path, with evidence about the artifacts it can read or change. Removing one broad production key is a meaningful step, but it does not complete the supply-chain review.
Runtime retrieval still needs a bootstrap explanation
An architect proposes moving every credential to a secret service and fetching values when the application starts. This can improve distribution and auditing, but the application still needs an authorized way to ask for its secrets. The inspection asks what establishes that caller's identity and which values it may retrieve.
If the answer is a broad secret-service administrator token stored in the same shared build configuration, the design may have exchanged several credentials for a more powerful one. The number of environment variables fell while the reachable authority increased. Cedar evaluates the effective permission boundary rather than counting secret strings as a security score.
A better scoped design can grant the running workload access to its own approved secret set through a supported identity mechanism. The owner verifies the issuer, audience or equivalent target binding, workload conditions, and resource permissions according to the actual service. This is an architectural option, not a claim that any hosting account automatically provides a particular identity feature.
Retrieval timing creates an availability question too. If the secret service is unavailable during a restart, the application needs a defined startup behavior. Silently substituting an old value from an untracked local file would undermine the rotation contract. Failing clearly, using an explicitly controlled cache, or delaying startup are different choices whose consequences should be tested.
The application also needs a refresh policy. Fetching once at startup differs from refreshing a credential periodically or responding to a revocation signal. The team records which generation a process has accepted and how a failed refresh affects its work. A secret-service migration does not remove the distinction between stored configuration and active process state.
Finally, the team checks who can change the retrieval policy. A process allowed to request any environment's secret may reach production even if its nominal deployment is staging. Resource naming and access checks must enforce the intended separation. The useful result is a smaller, demonstrable authority for the runtime, with the build excluded from that authority, rather than a new central service whose convenience conceals the old broad access.
Leave the inspection with fewer unexplained permissions
The accepted design gives Cedar's build only the private-artifact access it requires, keeps production database authority at the approved runtime boundary, and separates deployment promotion from compilation. It also removes secret-bearing diagnostics and documents the cache and artifact paths that remain part of the process.
The owner schedules review when a new build plugin, private dependency, deployment target, or identity relationship is added. These are events that can change authority, not merely reasons to update a drawing. A new tool should explain the access it needs before the pipeline grants it the entire existing configuration set.
The strongest outcome is an understandable build: its required inputs are known, its sensitive authority has a purpose, its outputs have been inspected under relevant failures, and its deployment path promotes the intended artifact. That makes the next secret incident smaller because the organization can explain which rooms the credential could enter and which doors were never open to it.