Dependencies on Brian Faust

A Lockfile Gives Repeatability, Not Provenance

Mon, 01 Dec 2025 00:00:00 +0000

composer install exits successfully. It selects the version in the committed lockfile, downloads an archive whose checksum matches, generates the autoloader, and produces the same output on a second clean install.

The output is EXFILTRATED.

Nothing about that result means Composer ignored the lock. The lockfile was updated to select the malicious package and its correct checksum. Composer did exactly what it was told and repeated that decision.

This is the useful boundary of a dependency lock. It records a resolution. It can make later installations select the same versions, references, metadata, and declared distribution bytes. It cannot prove who deserved to publish those bytes, why the update was approved, what package code will do, whether new advisories exist, or which artifact a consumer eventually executes.

Supply-Chain Security Begins with Who Can Change the Artifact

Sat, 01 Nov 2025 00:00:00 +0000

quote-tool.bin has a valid signature. Its provenance names the expected source revision, dependency lock, workflow digest, and builder. The signature verifies against the consumer’s trusted fixture key.

The program is still malicious.

In the SEC-01 fixture , the authorized builder changes the artifact after the tests pass and signs the resulting digest. Signature verification succeeds because the statement is authentic. Consumer policy rejects the artifact because its digest does not match the independently reproduced output.

Dependency Inversion Lets Policy Own the Boundary

Tue, 01 Jun 2021 00:00:00 +0000

This class uses constructor injection and still points in the wrong direction:

final readonly class QuoteShipment
{
 public function __construct(private GuzzleHttp\Client $http) {}

 public function handle(Shipment $shipment): Money
 {
 $response = $this->http->post('/carrier/rates', [
 'json' => CarrierPayload::fromShipment($shipment),
 ]);

 return Money::EUR(
 json_decode($response->getBody(), true)['price_cents'],
 );
 }
}

The constructor is cleaner, but the direction is still wrong. The application use case knows an HTTP client, carrier endpoint, payload, response shape, and currency assumption. Moving new Client() into the container made assembly easier. It did nothing to keep carrier details out of application policy.

The Type a Caller Receives Defines the Role

Sun, 01 Nov 2020 00:00:00 +0000

A payment driver received a client through a factory. The factory promised a five-operation interface. The concrete client had nine additional public methods.

Those extra methods covered token charging, status checks, settlement, cancellation, token management, payment-method lookup, and refund cancellation. None of the callers used them. When the transport was replaced, all nine disappeared along with more than a hundred lines of concrete client code.

The driver did not change, nor did its interface or factory interface. That is what a narrow collaboration buys: not fewer methods everywhere, but a smaller answer to “what may this caller rely on?”