Written by Jaiz Anuar

The Certificate Was Valid. The Software Update Was Malicious.

Modern software trust requires more than a valid signature. Source integrity, dependency control, build provenance, protected signing infrastructure and post-installation defence must support the final certificate.

For years, one of the basic rules of secure software distribution has been simple: verify the signature.

If the software is digitally signed by a trusted vendor, the certificate is valid and the package has not been modified after signing, we tend to trust the update.

That model still matters.

But modern software supply-chain attacks expose an uncomfortable problem.

A valid signature can prove who signed the software. It cannot prove that the software was safe before it was signed.

That distinction is becoming increasingly important.

Trusting The Signature Is Not The Same As Trusting The Software

Code signing provides something valuable. It helps verify authenticity and integrity. If a legitimate vendor signs a software package, the receiving system can confirm that the package came through the expected signing process and has not been altered afterwards.

But imagine the compromise happens earlier.

An attacker gains access to the vendor's development environment. They manipulate source code, poison a dependency, modify the build process or compromise a CI/CD pipeline.

The malicious component then enters the legitimate build.

The vendor signs the resulting software with a perfectly valid certificate.

From the customer's perspective, everything may look normal.

The certificate is trusted.

The signature validates.

The update arrives through the official channel.

And the software is malicious.

The cryptography did not fail.

The trust process did.

The Build Pipeline Is Part Of The Security Perimeter

This changes how we should think about software security architecture.

Many organisations focus heavily on securing the application after deployment. They protect endpoints, monitor networks, scan vulnerabilities and control privileged access.

But increasingly, some of the most important security decisions happen before the software reaches production.

Source repositories.

Build servers.

Package registries.

CI/CD pipelines.

Dependency repositories.

Signing infrastructure.

Release platforms.

These systems are not simply development tooling anymore.

They are part of the software trust chain.

If an attacker compromises that chain, they may not need to bypass security controls on thousands of customer systems individually.

They can attempt to make trusted systems distribute the malicious software for them.

A Trusted Update Channel Can Become A Privileged Attack Path

Automatic software updates are designed for good reasons.

Security patches need to be deployed quickly. Applications require maintenance. Customers expect fixes without complicated manual processes.

The architecture therefore gives update mechanisms considerable trust.

Sometimes they can download software, execute installers, restart services and replace privileged components.

That makes the update channel powerful.

And anything with that level of authority deserves to be treated as a privileged attack path.

The question should not only be:

“Is this update signed?”

We should also ask:

“What evidence do we have about how this software was produced?”

That is where software provenance becomes increasingly important.

Provenance Answers A Different Question

An SBOM can tell us what components exist inside software.

A digital signature can tell us who signed the package and whether it changed afterwards.

Software provenance goes further.

It helps answer questions such as: Where did this build originate? Which source produced it? Which dependencies were included? What build process created the binary? Which environment performed the build? Who authorised the release?

These are different forms of evidence.

And modern software security increasingly needs all of them.

Trust should not depend on one certificate at the final stage of a long supply chain.

The Signing Infrastructure Is A Crown Jewel

There is another architectural implication.

If attackers can compromise the signing process itself, they may be able to make malicious software appear legitimate.

Signing keys should therefore be treated as some of the most sensitive credentials in the software delivery environment.

They should not sit casually inside build scripts or broadly accessible developer systems.

Access should be tightly controlled. Signing operations should be auditable. Keys should be protected using appropriate cryptographic key-management infrastructure. Release processes should require strong separation of duties.

Ideally, compromising a developer workstation should not automatically provide a path to signing production software.

This is the same principle we apply elsewhere in security architecture.

A single compromise should not automatically compromise the entire trust chain.

Security Reviews Need To Look Upstream

Enterprise software assessments often focus on the software itself.

Does it support encryption?

Does it integrate with SSO?

Has the vendor performed penetration testing?

Does the product contain known vulnerabilities?

Those questions still matter.

But supply-chain risk requires another set of questions.

How does the vendor secure its development environment? How are dependencies managed? How are production builds isolated? How are releases authorised? How are signing keys protected? Can the vendor provide evidence of build provenance?

For critical software, those questions should become part of architecture and third-party security assessment.

Because by the time malicious code arrives as a perfectly signed package, many opportunities to stop the attack have already passed.

Defence In Depth Must Continue After Verification

Even trusted software should not automatically receive unlimited trust after installation.

Application allowlisting, endpoint monitoring, behavioural detection, network segmentation and least privilege still matter.

Why?

Because provenance can fail.

Certificates can be compromised.

Build pipelines can be breached.

Trusted vendors can make mistakes.

Security architecture should therefore assume that even something arriving through a trusted channel may eventually behave unexpectedly.

The signature should contribute to the trust decision.

It should not end the trust decision.

Final Thoughts

Digital signatures remain essential.

Code signing remains essential.

Software update mechanisms remain essential.

The mistake is assuming that any one of them can answer every question about trust.

A valid certificate tells us something important.

But it does not tell us everything.

As software supply chains become more complex, organisations will need stronger evidence about how software was developed, built, signed and distributed.

The future of software trust will therefore depend less on a single signal and more on a chain of verifiable evidence.

Because one day the certificate may be valid.

The vendor may be trusted.

The update may arrive through the official channel.

And the software may still be malicious.

Question assumptions. Share knowledge. Build trust.