# 🔎 PHASE 1 — Build System Context Reconstruction ## 1.1 Reconstructed architecture GitHub Repository Source code and workflow definitions Dependency Resolution npm + package-lock.json GitHub Actions Shared self-hosted runner Build and ZIP Creation Production application bundle Cloud Artifact Storage Publication and storage controls unknown Production Deployment Signature and provenance checks not documented ## 1.2 Stage-by-stage audit | Stage | Inputs and outputs | Trust control | Assessment | | ------------ | ------------------------------ | --------------------------------- | ---------------------------- | | Source | Git commits and workflow files | PR review | Partially documented | | Dependencies | npm packages and lockfile | Dependency scanning | Lockfile enforcement unknown | | Execution | Workflow and runner | Runner isolation | Potential concern | | Build | Source, tools and dependencies | Version pinning | Not documented | | Artifact | ZIP bundle | Digest verification | Not documented | | Publication | Cloud storage | Write restrictions | Unknown | | Release | Downloaded ZIP | Signature/provenance verification | Not documented | Phase 1 finding: The delivery path is identifiable, but critical evidence is missing at the artifact-to-production boundary. - Confirmed from sample inputs: a shared self-hosted runner is used. - Potential risk: another workflow might influence a build through shared state. - Unknown: whether runner isolation, cleanup, and access controls already prevent that scenario. # 🧱 PHASE 2 — Trust Boundary & Build Authority Analysis ## 2.1 Trust boundary matrix | Identity or component | Potential authority | Risk | Required verification | | ------------------------ | -------------------------- | ------------------------------- | ---------------------------------------- | | Repository maintainer | Modify workflow files | Build logic changes | Branch rules and audit logs | | Pull request contributor | Submit code changes | Untrusted code execution | Trigger configuration and approval rules | | CI service identity | Execute and publish builds | Excessive permissions | Workflow token permissions | | Runner administrator | Control build environment | Persistent compromise | Host administration and isolation | | Package publisher | Supply dependency updates | Dependency substitution | Lockfile and package integrity | | Artifact publisher | Upload or replace ZIP | Artifact substitution | Storage IAM and immutability | | Release operator | Deploy production artifact | Unauthorized release | Independent approval and identity checks | | Signing authority | Sign artifacts | False trust in malicious output | Key access and signing policy | ## 2.2 Potential abuse paths Path A: Workflow modification - Preconditions: An attacker gains sufficient repository permissions, or an unauthorized workflow change is accepted. - Potential outcome: The build process could be changed to produce an unintended artifact. - Evidence: Two maintainers can modify workflow files; the approval and protection rules are unknown. - Recommended control: Protect workflow files with mandatory independent review and branch protection. Path B: Shared runner contamination - Preconditions: A workflow can persist or manipulate state that a later workflow consumes, and isolation controls fail to prevent it. - Potential outcome: A later build could be influenced by an earlier execution. - Evidence: The runner is shared; cleanup and isolation are unknown. - Recommended control: Use ephemeral isolated runners for sensitive release builds, or demonstrate equivalent enforced isolation. Path C: Artifact replacement - Preconditions: An unauthorized identity can modify cloud storage, or deployment resolves a mutable artifact reference without trusted verification. - Potential outcome: Production may receive a different artifact from the one originally built. - Evidence: Deployment downloads a ZIP; permissions and verification are undocumented. - Recommended control: Verify the artifact digest against a trusted release record and enforce storage access restrictions. Phase 2 conclusion: No successful attack is demonstrated. The primary concern is whether independent controls prevent one compromised identity from influencing both build production and release authorization. # ⚠️ PHASE 3 — Build Pipeline Tampering Risk Analysis | ID | Potential tampering mechanism | Evidence | Severity | Detection opportunity | | ---- | ------------------------------ | -------------------------------------------------------- | -------------- | ------------------------------------------ | | T-01 | Unauthorized workflow changes | Maintainers can modify workflows; protection unknown | High potential | Workflow change audit logs | | T-02 | Cross-job runner contamination | Shared runner; isolation unknown | High potential | Clean-run comparison and runner inspection | | T-03 | Artifact substitution | Cloud storage controls unknown | High potential | Digest verification at deployment | | T-04 | Unpinned toolchain | Versions not explicitly pinned in supplied configuration | Medium | Build environment inventory | | T-05 | Release authorization bypass | Approval rules unknown | High potential | Release audit log and policy tests | These are potential risks, not confirmed exploits. Severity is provisional and must be adjusted after checking actual permissions, exposure, and compensating controls. ### Recommended tampering safeguards - Require reviewed changes to production build definitions. - Prevent untrusted pull requests from accessing release secrets. - Isolate release builds from untrusted workloads. - Compare the artifact digest at creation, publication, and deployment. - Block deployment when the release's trusted identity or artifact digest cannot be verified. # 🔗 PHASE 4 — Dependency Injection & Build Input Integrity ## 4.1 Dependency assessment | Check | Sample evidence | Risk | Recommended action | | ---------------------- | --------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------- | | Lockfile | `package-lock.json` exists | Presence alone does not prove enforcement | Use `npm ci` with a committed lockfile | | Package integrity | Not verified | Substituted package content may go undetected if controls are insufficient | Verify lockfile integrity metadata and registry behavior | | Registry configuration | Public npm registry | Source is identified, but package trust is not guaranteed | Enforce approved registry configuration | | Dependency versions | Actual manifest unavailable | Version constraints cannot be assessed | Review manifest and lockfile | | Build plugins | Not supplied | Executable plugin risk unknown | Inventory and review build-time plugins | | Remote scripts | Not supplied | Download and execution behavior unknown | Inspect workflow commands and build scripts | | Container images | Not specified | Image pinning cannot be assessed | If used, pin trusted image digests | ### Example validation Run in an authorized test branch: ``` npm ci npm ls --all npm audit ``` Interpretation: - `npm ci` tests whether dependencies can be installed consistently from the lockfile. - `npm ls --all` helps inspect the resolved dependency tree. - `npm audit` checks reported dependency vulnerabilities, not overall build integrity. Expected result: The installation follows the committed lockfile, the dependency tree is explainable, and unexpected registry or dependency changes are detected by the review process. A successful installation is not proof that every dependency is trustworthy. # 🛠️ PHASE 5 — Build Script, Toolchain & Execution Audit ## 5.1 Findings B-01: Toolchain versions are not documented as pinned - Evidence: The supplied configuration does not explicitly pin Node.js and npm versions. - Potential consequence: Different environments could resolve tools differently, producing inconsistent outputs. - Mitigation: Pin supported Node.js versions and define the package manager version in the build environment. - Validation: Record actual runtime and package manager versions in the build logs. B-02: Build scripts have not been supplied for review - Evidence: No script contents or workflow YAML were provided. - Potential consequence: Unexpected commands, unsafe code generation, or external downloads cannot be ruled out. - Mitigation: Review `package.json` scripts, workflow commands, and inherited build configuration. - Validation: Trace every production build step to a reviewed definition. Example inventory command: ``` node --version npm --version npm run ``` The output should be captured as evidence. Do not assume a particular version or script exists before executing these commands. # 🏗️ PHASE 6 — CI/CD Runner & Environment Isolation Audit ## 6.1 Runner risk review | Control | Current evidence | Recommendation | | ----------------------- | ----------------------- | ----------------------------------------------------- | | Ephemeral execution | Unknown | Prefer fresh runner environments for release builds | | Workspace cleanup | Unknown | Verify cleanup after successful and failed jobs | | Cross-job state | Shared runner confirmed | Test for unintended state reuse | | Network access | Unknown | Restrict outbound traffic where practical | | Filesystem permissions | Unknown | Run builds with minimal host privileges | | Container privileges | Unknown | Review only if containers are used | | Untrusted contributions | Trigger rules unknown | Separate PR validation from trusted release builds | | Cache reuse | Unknown | Scope caches by trust level and validate cache inputs | ### Safe validation test 1. Create a harmless marker file in an authorized test job. 2. End the job normally. 3. Run a separate job on the intended release runner pool. 4. Check whether the marker remains accessible. 5. Repeat after a deliberately failed test job. 6. Record runner identity, workspace cleanup, and isolation results. Expected result: A later job cannot access unintended state from the earlier job. A shared runner is not automatically insecure; the issue is whether the enforced isolation matches the trust level of the workloads. # 🔐 PHASE 7 — Build Secrets, Identity & Signing Authority ## 7.1 Identity and credential assessment | Area | Evidence | Risk | Recommended control | | ------------------- | ------------------------------ | ----------------------------- | --------------------------------------------- | | Repository tokens | Permissions unknown | Excessive repository access | Restrict token scopes | | Cloud credentials | Injection method unknown | Unauthorized publication | Use least-privilege identities | | Deployment secrets | Exposure to build jobs unknown | Release path compromise | Keep production secrets out of untrusted jobs | | Signing keys | Process undocumented | Unauthorized signing | Use a protected signing service | | Credential lifetime | Unknown | Persistent credential misuse | Prefer short-lived credentials | | Logs | Not provided | Accidental disclosure unknown | Redact secrets and inspect log access | ### Critical design rule Ordinary build permission must not automatically imply signing or production release authority. Recommended separation: - Build identity: Compiles and produces an artifact. - Publication identity: Publishes only authorized build outputs. - Signing authority: Signs only artifacts meeting the release policy. - Deployment identity: Deploys only verified and approved artifacts. ### Validation test Attempt to run an authorized non-release test workflow and verify that it cannot: - Access production deployment credentials. - Sign production artifacts. - Publish into protected release locations. Expected result: The workflow is denied access to all unnecessary release privileges, and the denial is recorded. This is a proposed test, not an executed test. # 📦 PHASE 8 — Artifact Integrity & Immutability Audit ## 8.1 Artifact verification design The sample system creates a ZIP and stores it in cloud storage. The existence of an uploaded ZIP does not establish that the artifact is authentic or unchanged. Recommended artifact identity: - Unique release identifier. - Exact source commit. - Cryptographic SHA-256 digest. - Build run identifier. - Trusted provenance reference, when available. - Verified signature or attestation identity, where required. Generate a digest in a controlled build environment: ``` sha256sum release.zip ``` At deployment time: 1. Retrieve the expected digest from a trusted release record. 2. Calculate the digest of the downloaded ZIP. 3. Compare the calculated and expected digests. 4. Reject deployment if they differ. 5. Record the result and artifact identifier. Important: If an attacker can modify both the artifact and the expected digest, the comparison may still pass. Protect the reference digest through independent access controls, signed metadata, or a trusted attestation policy. ### Finding A-01 - Evidence: Artifact signing, immutable storage, and deployment-time digest checks are not documented. - Severity: High potential. - Confidence: Medium that the documentation is incomplete; low confidence that the controls are actually absent. - Mitigation: Implement trusted digest verification and restrict artifact replacement permissions. - Validation: Demonstrate that a modified test artifact is rejected by the deployment gate. # 🧾 PHASE 9 — Build Provenance & Attestation Analysis ## 9.1 Required provenance fields | Field | Supplied evidence | Status | | ---------------------- | ----------------------------- | ----------------------------------------------- | | Source revision | Repository exists | Exact commit linkage unknown | | Build definition | Workflow exists | Definition identity unknown | | Builder identity | GitHub Actions | Exact trusted identity unknown | | Dependencies | Lockfile exists | Actual resolved inputs not captured in evidence | | Artifact digest | ZIP created | Recorded digest unknown | | Provenance attestation | Not documented | Availability and verification unknown | | Signature policy | Not documented | Unknown | | Release verification | ZIP downloaded for deployment | Enforcement unknown | ### Recommended approach Use a provenance format appropriate to the build ecosystem, such as an in-toto attestation with SLSA provenance. The release policy should validate: - The expected repository and source revision. - The authorized workflow and builder identity. - The artifact digest. - The expected build parameters and relevant inputs. - The attestation issuer and signature trust policy. A provenance file is not sufficient by itself. Its signature, identity, contents, and relationship to the deployed artifact must be verified. # 🔍 PHASE 10 — Reproducibility & Build Consistency ## 10.1 Reproducibility assessment | Property | Current status | Required evidence | | --------------------------- | ------------------------------------ | ------------------------------------------------- | | Pinned toolchain | Not documented | Version inventory and build configuration | | Consistent dependencies | Lockfile exists; enforcement unknown | Clean installation logs | | Repeatable build process | Unknown | Repeated clean builds | | Bit-for-bit reproducibility | Unknown | Independent artifact digest comparison | | Functional equivalence | Unknown | Application behavior tests | | Cache independence | Unknown | Comparison between clean and cache-enabled builds | ### Proposed experiment 1. Check out the same approved source commit in two clean environments. 2. Use identical, explicitly recorded toolchain versions. 3. Resolve dependencies using the committed lockfile. 4. Build without sharing writable workspace state. 5. Compare SHA-256 digests of the resulting artifacts. 6. If digests differ, compare normalized contents and investigate timestamps, generated metadata, ordering, and environment-dependent behavior. Expected result: Identical inputs and controlled conditions produce identical artifacts if bit-for-bit reproducibility is a stated requirement. A mismatch is a signal to investigate, not proof of tampering. A match is useful evidence, but it does not independently prove source trustworthiness. # 📊 PHASE 11 — Build Integrity Risk Prioritization The following register ranks potential risks from the sample evidence. These are preliminary priorities, not confirmed vulnerabilities. | ID | Finding | Severity | Confidence | Affected stage | Recommended control | | ---- | ------------------------------------------------ | -------------- | ------------------------------- | ----------------------- | ---------------------------------------- | | R-01 | Deployment artifact verification is undocumented | High potential | Medium | Publication/deployment | Trusted digest verification | | R-02 | Shared runner isolation is unverified | High potential | Medium | Build execution | Isolated release runners | | R-03 | Signing authority and policy are undocumented | High potential | Medium | Signing/release | Protected signing service | | R-04 | Workflow protection rules are unknown | High potential | Medium | Source/build definition | Branch protection and independent review | | R-05 | Release approval controls are unknown | High potential | Medium | Release | Independent authorization | | R-06 | Toolchain versions are not documented as pinned | Medium | High for supplied configuration | Build execution | Pin and record toolchain versions | | R-07 | Dependency lockfile enforcement is unknown | Medium | Medium | Dependency resolution | Enforce `npm ci` | | R-08 | Source-to-artifact provenance is undocumented | High potential | Medium | Build/release | Verified provenance policy | Prioritization rationale: Artifact verification and release trust come first because they determine whether production receives the intended artifact. Runner isolation, workflow permissions, and signing separation are next because they protect the systems that create and authorize that artifact. # 🛡️ PHASE 12 — Prevention, Detection & Containment Controls | Control | Owner | Trigger | Required evidence | Expected outcome | | -------------------------- | ------------------------ | ----------------------- | --------------------------------------------- | -------------------------------- | | Protected workflow changes | Repository administrator | Workflow modification | Review and branch protection logs | Unauthorized changes blocked | | Dependency integrity | Build engineer | Dependency installation | Lockfile and installation logs | Unexpected resolution detected | | Runner isolation | CI/CD administrator | Every build | Runner identity and cleanup records | Cross-job influence prevented | | Least-privilege identity | Cloud/security engineer | Workflow execution | Permission policy and access logs | Excessive access denied | | Artifact digest gate | Release engineer | Artifact promotion | Trusted expected digest and calculated digest | Modified artifact rejected | | Signing separation | Security engineer | Signing request | Signing audit record | Only authorized artifacts signed | | Provenance verification | Release engineer | Deployment | Validated attestation and identity | Untrusted provenance rejected | | Incident quarantine | Incident commander | Integrity alert | Preserved artifact and event logs | Suspicious releases blocked | ### Recommended enforcement order - Prevent: Protect workflow changes, restrict identities, isolate release builds. - Detect: Record inputs and verify artifact digests. - Contain: Block failed verification, quarantine artifacts, preserve logs, and revoke credentials when exposure is confirmed. # 🧪 PHASE 13 — Build Integrity Verification & Test Design All tests below are proposed. No test has been executed against an actual pipeline. ## Test 1: Source revision traceability - Objective: Verify that a release maps to an approved commit. - Preconditions: A test release and repository access. - Method: Compare the release record, build run, and source commit. - Expected result: All identifiers match the approved release. - Failure condition: Missing or inconsistent commit identity. - Evidence: Commit SHA, workflow run ID, release record. - Remediation: Enforce source revision recording. ## Test 2: Workflow permission enforcement - Objective: Verify unauthorized workflow modifications are blocked. - Preconditions: Authorized test repository. - Method: Attempt a controlled modification without required approval. - Expected result: The change cannot enter the protected release branch. - Failure condition: An unapproved change can trigger a trusted release. - Evidence: Branch rules, review records, audit logs. - Remediation: Enforce protection and independent review. ## Test 3: Dependency integrity - Objective: Verify dependencies follow the committed lockfile. - Preconditions: Clean test runner and committed lockfile. - Method: Run `npm ci`, inspect the resolved dependency tree, and compare the lockfile. - Expected result: Installation succeeds without unexplained dependency changes. - Failure condition: Unexpected registry use or dependency resolution. - Evidence: Lockfile, npm configuration, installation logs. - Remediation: Enforce registry policy and investigate mismatches. ## Test 4: Runner isolation - Objective: Verify jobs cannot reuse unauthorized workspace state. - Preconditions: Disposable authorized runners. - Method: Perform the marker-file isolation experiment from Phase 6. - Expected result: Unintended cross-job state is inaccessible. - Failure condition: A later job accesses unauthorized state. - Evidence: Runner logs and workspace inspection. - Remediation: Use stronger isolation or ephemeral runners. ## Test 5: Secret exposure - Objective: Verify untrusted jobs cannot access production secrets. - Preconditions: Non-production test workflow. - Method: Inspect effective permissions and use harmless access-denial tests. - Expected result: Production secrets are unavailable to untrusted jobs. - Failure condition: Unauthorized access succeeds. - Evidence: Policy configuration and redacted audit logs. - Remediation: Remove secret access and rotate credentials if exposure is confirmed. ## Test 6: Artifact digest verification - Objective: Detect artifact modification. - Preconditions: Disposable artifact and trusted expected digest. - Method: Calculate the original digest, modify a copy, and run the release verification gate. - Expected result: The modified copy is rejected. - Failure condition: The altered copy passes verification. - Evidence: Original and modified digests, gate logs. - Remediation: Correct the comparison logic and protect the expected digest. ## Test 7: Signature and signing identity - Objective: Reject artifacts with invalid signatures or unauthorized signers. - Preconditions: Test signing identity and verification policy. - Method: Test a valid signed artifact, an altered artifact, and an artifact signed by an untrusted test identity. - Expected result: Only the artifact meeting the trusted identity and signature policy passes. - Failure condition: An invalid or untrusted signature is accepted. - Evidence: Signature verification output and trust policy. - Remediation: Enforce signature and identity verification. ## Test 8: Provenance verification - Objective: Confirm the artifact matches an approved source and builder. - Preconditions: A test attestation and trusted identity policy. - Method: Validate issuer, repository, commit, builder, and artifact digest. - Expected result: Valid provenance passes; mismatched provenance is rejected. - Failure condition: Missing or inconsistent provenance is accepted. - Evidence: Attestation and verification logs. - Remediation: Enforce provenance policy at release time. ## Test 9: Reproducible build - Objective: Assess output consistency. - Preconditions: Two clean environments and identical declared inputs. - Method: Build twice and compare digests. - Expected result: Identical digests if bit-for-bit reproducibility is required. - Failure condition: Unexplained output differences. - Evidence: Build logs, tool versions, digests. - Remediation: Investigate nondeterministic inputs and build steps. ## Test 10: Artifact promotion and release authorization - Objective: Ensure only verified artifacts can reach production. - Preconditions: Test release environment. - Method: Attempt promotion with an unauthorized release identity and an intentionally invalid test artifact. - Expected result: Both unauthorized promotion and invalid artifact deployment are blocked. - Failure condition: Either attempt succeeds. - Evidence: Approval records, access logs, verification results. - Remediation: Enforce independent authorization and artifact verification gates. # 🔄 PHASE 14 — Incident Response & Artifact Recovery | Incident | Immediate response | Investigation and recovery | | --------------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Unexpected artifact digest | Block deployment and quarantine artifact | Preserve original files, identify affected releases, rebuild from trusted inputs | | Invalid signature | Reject artifact | Investigate signer identity, signing logs, and release records | | Provenance mismatch | Stop promotion | Compare source commit, builder identity, inputs, and attestation | | Unauthorized workflow change | Disable affected release path | Preserve workflow history and audit logs, review all builds since the change | | Suspicious dependency update | Pause affected releases | Compare manifests, lockfiles, registry records, and build history | | Suspected runner compromise | Isolate runner | Preserve available evidence, investigate other jobs, rebuild on clean infrastructure | | Exposed signing credential | Disable or revoke affected credential | Review signing history, determine scope, rotate or replace credentials, reassess releases | | Unauthorized artifact publication | Restrict publication access | Identify modified artifacts and consumers, republish verified artifacts through a controlled process | ### Incident handling sequence 1. Detect and classify the integrity alert. 2. Block affected releases or deployments. 3. Preserve artifacts, digests, logs, workflow history, and relevant access records. 4. Determine which builds and releases could be affected. 5. Investigate source changes, dependency changes, runner activity, and signing events. 6. Revoke credentials when exposure or compromise warrants it. 7. Rebuild using trusted source, dependencies, and toolchains. 8. Independently verify the artifact and provenance. 9. Republish and redeploy through approved controls. 10. Document root cause and add regression tests. Evidence preservation comes before cleanup or overwriting whenever practical. A suspicious artifact is not automatically proof of confirmed compromise. # 🗺️ PHASE 15 — Secure Build Hardening Roadmap Stage 1 — Immediate Integrity Controls Highest priority - Enforce artifact digest verification before deployment. - Protect workflow changes and production release authorization. - Restrict artifact storage modification rights. Owner: DevSecOps / Release Engineering. Effort: Low to medium. Completion: Unauthorized changes and mismatched artifacts are blocked in tests. Stage 2 — Build Input Hardening - Enforce lockfile-based dependency installation. - Pin and record toolchain versions. - Review build scripts and external executable inputs. Owner: Application / Build Engineering. Effort: Low to medium. Completion: Clean builds use documented, controlled inputs. Stage 3 — Environment & Identity Isolation - Isolate release runners. - Remove unnecessary permissions and secrets. - Separate build, signing, publication, and deployment identities. Owner: CI/CD and Cloud Security. Effort: Medium. Completion: Isolation and permission-denial tests pass. Stage 4 — Provenance & Traceability - Record source revision, builder identity, and artifact digest. - Generate provenance attestations. - Verify attestations against a defined trust policy. Owner: Supply Chain Security. Effort: Medium. Completion: A release can be traced and independently verified. Stage 5 — Continuous Verification - Automate integrity and provenance gates. - Monitor workflow changes and privileged actions. - Schedule reproducibility and recovery tests. Owner: DevSecOps / Security Operations. Effort: Medium. Completion: Failed integrity checks reliably block release and create auditable evidence. # 🏆 PHASE 16 — Final Software Build Integrity Report ## 16.1 Executive Summary The fictional e-commerce pipeline uses GitHub, npm, GitHub Actions, a shared self-hosted runner, cloud artifact storage, and production deployment. The primary concern is insufficient documented evidence connecting the approved source revision to the exact artifact deployed in production. The most important priorities are: - Enforce artifact digest verification. - Protect workflow modification and release authorization. - Validate runner isolation. - Separate build permissions from signing and deployment authority. - Record and verify build provenance. The evidence does not demonstrate a successful attack or a compromised release. Several controls may exist but were not included in the sample inputs. ## 16.2 Source-to-Artifact Architecture Map Source repository → Dependency resolution → CI runner → Build and tests → ZIP artifact → Cloud storage → Release verification → Production deployment. The main trust boundaries are: - Repository changes to executable build definitions. - External dependencies to the build environment. - Runner execution to artifact creation. - Artifact publication to production consumption. - Build identity to signing and deployment authority. ## 16.3 Trust Boundary & Build Authority Matrix | Boundary | Main concern | Required proof | | ---------------------- | ----------------------------------- | ------------------------------------- | | Source to build | Unapproved code or workflow changes | Branch protection and review records | | Dependencies to build | Unexpected package inputs | Lockfile and registry enforcement | | Runner to artifact | Cross-job influence | Isolation evidence | | Build to storage | Unauthorized artifact replacement | Storage IAM and immutable references | | Artifact to production | Incorrect artifact deployed | Trusted digest verification | | Build to signing | Unauthorized signing | Signing service policy and audit logs | | Release to production | Approval bypass | Independent authorization records | ## 16.4 Build Pipeline Tampering Risk Register - T-01: Workflow changes could influence production builds if protections are insufficient. - T-02: Shared runner state could affect later jobs if isolation fails. - T-03: Cloud-stored artifacts could be replaced if permissions and verification are insufficient. - T-04: Unpinned toolchains could reduce build consistency. - T-05: Release authorization controls require verification. No tampering event is confirmed. ## 16.5 Dependency Injection & Build Input Analysis The committed lockfile is a useful control, but its enforcement and integrity metadata must be validated. Dependency scanning alone does not guarantee that the installed dependency set is trusted. Priority actions: - Use `npm ci`. - Enforce approved registry configuration. - Review dependency changes. - Pin toolchain versions. - Inventory plugins and remote downloads. ## 16.6 Build Script & Toolchain Audit The actual workflow YAML, `package.json`, and toolchain configuration were not supplied. Therefore, script execution behavior, inherited configuration, and tool downloads remain unverified. The first evidence collection task is to review the actual build definition and record the versions and commands executed in the production build. ## 16.7 CI/CD Runner & Isolation Audit A shared self-hosted runner is confirmed in the sample. Its actual isolation strength is unknown. Prioritize clean release execution, restricted network and filesystem access, controlled cache use, and verification that untrusted workflows cannot influence trusted release builds. ## 16.8 Secrets, Identity & Signing Authority Audit No actual credential exposure is established. Credential scopes, signing authority, and deployment permissions remain unknown. The essential control is separation of build, publication, signing, and deployment identities, with short-lived credentials where supported. ## 16.9 Artifact Integrity & Immutability Audit Artifact digest enforcement, storage immutability, and deployment-time verification are not documented. Implement a trusted digest comparison and restrict who can alter both artifacts and the reference metadata used to verify them. ## 16.10 Provenance & Reproducibility Assessment The sample does not establish that the deployed ZIP is traceable to an approved commit and trusted builder. Generate provenance, verify its signing identity and policy, and test reproducibility in clean environments. Do not interpret missing documentation as proof that these controls are absent. ## 16.11 Prioritized Build Integrity Risk Register | ID | Finding | Evidence | Severity | Confidence | Affected stage | Recommended control | | ---- | ------------------------------------ | --------------------------------------------------- | -------------- | ----------------------------- | -------------- | --------------------------- | | R-01 | Artifact verification undocumented | ZIP downloaded for deployment; verification unknown | High potential | Medium | Release | Trusted digest gate | | R-02 | Runner isolation unverified | Shared runner | High potential | Medium | Build | Isolated release runners | | R-03 | Signing policy undocumented | No signing evidence supplied | High potential | Medium | Signing | Protected signing authority | | R-04 | Workflow protection unknown | Maintainers can modify workflows | High potential | Medium | Source/build | Independent review | | R-05 | Release approval unknown | No approval evidence supplied | High potential | Medium | Deployment | Independent authorization | | R-06 | Toolchain pinning undocumented | Versions not explicitly pinned in sample | Medium | High for sample configuration | Build | Pin and record versions | | R-07 | Lockfile enforcement unknown | Lockfile exists; `npm install` is used | Medium | Medium | Dependencies | Use `npm ci` | | R-08 | Provenance verification undocumented | No provenance evidence supplied | High potential | Medium | Build/release | Verify attestations | ## 16.12 Prevention, Detection & Containment Strategy - Prevention: Protect source changes, pin build inputs, isolate runners, and restrict permissions. - Detection: Monitor workflow changes, record artifact digests, and validate provenance. - Containment: Block failed releases, quarantine suspect artifacts, preserve evidence, and revoke affected credentials when justified. ## 16.13 Verification & Regression Test Plan Execute the ten proposed tests from Phase 13 in an authorized non-production environment. Capture actual logs, configuration exports, digests, approval records, and verification results. Do not mark any test as passed until the expected behavior has been demonstrated. ## 16.14 Incident Response & Artifact Recovery Plan On a suspected integrity failure: 1. Block the affected release. 2. Preserve relevant artifacts and audit logs. 3. Identify affected builds and deployments. 4. Investigate source, dependencies, runner state, and signing events. 5. Revoke credentials if compromise or exposure warrants it. 6. Rebuild from verified inputs. 7. Independently verify artifact identity and provenance. 8. Republish through the approved release path. ## 16.15 Secure Build Hardening Roadmap 1. Immediate: Add deployment-time digest verification and protect release authorization. 2. Next: Validate runner isolation and restrict build identities. 3. Next: Enforce lockfile installation and toolchain pinning. 4. Then: Establish verified provenance and signing policy. 5. Finally: Automate continuous verification and reproducibility testing. ## 16.16 FINAL BUILD INTEGRITY DECISION Highest-priority weaknesses - Deployment artifact verification is undocumented. - Shared runner isolation is unverified. - Signing authority and release permissions are insufficiently evidenced. - Source-to-artifact provenance is unverified. Confirmed versus potential risks - Confirmed sample facts: Shared self-hosted runner, ZIP artifact publication, deployment download, and lack of supplied evidence for several controls. - Potential risks: Cross-job contamination, artifact replacement, workflow abuse, unauthorized signing, and release approval bypass. - Confirmed tampering: None. Most critical trust boundaries - Source repository to build execution. - Runner to artifact creation. - Artifact storage to production. - Build identity to signing and deployment authority. Required validation evidence - Repository protection settings and workflow history. - Actual workflow YAML and toolchain versions. - Dependency lockfile and installation logs. - Runner isolation test results. - Storage access policies and digest comparison logs. - Signing verification and provenance validation results. - Production release authorization records. Residual risks Even after digest verification, an artifact may still contain unwanted code if its source or build process was compromised. A valid signature also does not automatically establish trustworthy origin unless the signer and signing policy are trusted. First three implementation actions 1. Enforce SHA-256 digest verification before deployment, using a trusted expected digest. 2. Verify workflow protection and runner isolation, then separate untrusted builds from release builds. 3. Separate signing and deployment authority from ordinary build permissions and require independent release verification. ### 🛡️ BUILD INTEGRITY VERDICT ## Insufficient evidence to assess integrity The sample provides enough information to identify important trust boundaries and potential weaknesses, but not enough to establish the actual security of the pipeline. No confirmed compromise has been demonstrated. The verdict could improve after successful artifact digest, signature, provenance, permission, and runner isolation tests. It could worsen if testing identifies an unauthorized release path, untrusted signing authority, or an artifact verification bypass.