We have trained users and security teams to look for signs of trust. A valid certificate. A trusted publisher. A familiar update mechanism. A clean-looking installer. For years, those signals helped us separate legitimate software from obvious malware.
The problem is that attackers understand those signals too.
That is why the argument in The Certificate Was Valid. The Software Update Was Malicious. is important. A digitally signed file can prove where the software came from, but it does not automatically prove that the software itself is safe.
If an attacker compromises the software vendor, build pipeline, signing process or update infrastructure, the malicious package may still arrive through a legitimate channel. From the user’s perspective, everything can look normal. The certificate is valid. The update prompt is familiar. The application trusts the package. Yet the content being delivered may already have been compromised.
This changes how we should think about software trust.
The old assumption was simple: if the update is signed by the right vendor, trust it. A better assumption today is that signing is only one part of the verification chain. Organisations still need controls around software integrity, update provenance, vendor security, behavioural monitoring and the ability to detect when trusted software starts doing something unexpected.
That is especially important because software supply chains have become deeply interconnected. One compromised component, build environment or update server can potentially affect thousands of downstream systems without requiring attackers to target each organisation individually.
The lesson is not that digital certificates have become useless. They are still essential.
The lesson is that identity is not the same as integrity, and integrity is not the same as safety.
A valid certificate should answer one question: who signed this?
Security still has to answer the harder one: should we trust what it is doing?