GitHub Actions lockfiles and an AWS SBOM inventory cover both ends of supply-chain hygiene
Serguey Asael Shinder1 min readTwo releases from the past ten days attack the software supply chain from opposite ends. On 28 October GitHub made workflow dependency lockfiles for GitHub Actions generally available; on 6 November AWS added an organisation-wide SBOM inventory to Security Hub. Neither is a new idea, but both now arrive as platform defaults rather than as tools a team has to assemble.
The GitHub feature addresses what a build executes. A workflow can keep readable tag and branch references while running the exact commits recorded in .github/workflows/actions.lock, generated by the gh actions-lock extension and covering transitive dependencies. Dependabot regenerates the lockfile entry in the same pull request when it bumps an action, administrators can require lockfiles by policy, and a check can verify that a lockfile is not stale. GitHub's own note is precise about the limit: lockfiles protect against unexpected dependency changes, but they do not determine whether a dependency is safe.
The AWS feature addresses what runs afterwards. Security Hub builds the inventory from the SBOMs Amazon Inspector already produces for EC2 instances, ECR images and Lambda functions, lists each package with its version and the number of resources carrying it, and exposes the result through its API at no extra cost where Inspector is enabled.
Put together, they cover the two questions an incident response asks first: did something change in what we build with, and where is the affected package running now. A moved tag in a popular action answers the first; a newly disclosed library flaw needs the second.
What it means
Pinning and inventory fail in different ways. A lockfile freezes whatever was there when it was generated, including a bad version; an inventory only sees resources the scanner covers. Each is worth turning on, and neither replaces reviewing a dependency before trusting it.