Ruby to PHP: The Software Supply Chain Is the Security Story
Why modern application security crosses Ruby gems, PHP packages, build systems and artifact registries.
The old security question was, “Is my framework patched?” The better question now is, “Can I explain every component that enters the build, every tool that can change it, and the exact artifact that reached production?”
How we got here
Applications stopped being single-language products a long time ago. A Laravel service may depend on PHP packages, Node packages, a container base image, a CI runner, a registry and a deployment script. A Rails service adds Ruby, gems and native extensions. The code may be different, but the delivery path has the same trust boundaries.
The 2025 OWASP Top 10 names this wider problem Software Supply Chain Failures. It includes repositories, build systems, dependencies, artifacts, registries, infrastructure-as-code and the people and credentials that connect them. That is why a Ruby advisory and a PHP advisory belong in the same engineering conversation.
The practical change
- Keep lock files under review, not just package manifests.
- Generate an inventory or SBOM for the build artifact.
- Review CI and deployment credentials as carefully as application secrets.
- Promote the tested artifact instead of rebuilding different bytes for every environment.
- Record the running commit and image digest after release.
The manager's test
Ask a team to name the exact dependency version, build result, artifact and production commit for yesterday's release. If the answer is “the pipeline was green”, the process is not yet giving enough evidence.
What the chain looks like on an ordinary morning
A developer opens a merge request. The package manager resolves a graph from the manifest and the lock file. A build runner downloads those packages, installs operating-system libraries, compiles assets and creates an image. The image is pushed to a registry. A deployment job pulls it, runs migrations and starts the service. Monitoring then checks a public endpoint. There are at least six places where the bytes or the permissions can differ from the developer's laptop.
That is why “we use Ruby” or “we use Laravel” is not a useful boundary. The vulnerability may be in a gem, a PHP package, a transitive Node dependency, a base image or the build machinery. It may also be introduced by a compromised account that can publish an otherwise valid-looking artifact.
Three controls worth adding this week
- Freeze the evidence. Save the lock-file diff, build identifier and artifact digest with the change record. This makes later triage possible without reconstructing yesterday's build.
- Separate promotion from compilation. Build once, test that result, then promote it. Rebuilding in production creates a second dependency-resolution event at the worst possible time.
- Make the release reversible. Keep the previous image or commit identifiable, keep a database backup policy, and define the health signal that stops an automatic rollout.
These controls are not a promise that a supply chain cannot fail. They reduce the time between a new advisory, a confident decision and a verifiable repair. That is the useful definition of security work for a small team: fewer unknowns when the alert arrives.
The same discipline also makes ordinary maintenance less dramatic. When the next Ruby, PHP or JavaScript advisory arrives, the team already knows where to look, which revision was tested and what evidence belongs in the ticket. Security becomes a repeatable operation rather than a late-night search through several machines.
Sources: OWASP Top 10:2025 A03 and Ruby security advisories.
