Digital Signature Identity: How Malware Gets Approved

Someone at a company you've heard of opened a software update last year. It had a digital signature, think of that as an official stamp of approval, like a notary seal on a legal document. It looked right. Every automated check said it was clean. The approval workflow waved it through. The update was malware.

Most of us picture "deepfake" and imagine a fake video of a politician saying something they never said, or a scam call that sounds like your kid. And yes, those are real and they're spreading fast. But there's a slower, less visible shift happening inside companies and software systems, one that's arguably harder to catch, because it doesn't look like a fake at all. It looks official.

That's the story worth paying attention to right now.

Deepfake software signature: Forged Badge Problem Explained

Here's a mental picture that might help. Imagine you work at a building with a badge-in security system. Every person who enters swipes a badge. The system checks: does this badge belong to an employee? Is the chip real? If yes, the door opens. Nobody stops to ask, "But is this person actually who the badge says they are?"

That's almost exactly the situation with software right now.

When a piece of software, an app update, a file, an internal tool, gets released inside a company, it usually comes with something called a digital signature. Think of this as a cryptographic stamp (a mathematical seal that's incredibly hard to forge) proving that a specific, trusted source created this file and that it hasn't been tampered with since. Your phone checks these automatically when you download apps. Your company's IT systems check them before installing anything. For years, this system worked well. This article is part of a series, start with Retail Facial Recognition Washington Privacy Gap.

The problem is that the signature only proves who signed itnot whether the signer was doing something trustworthy. And increasingly, attackers aren't trying to break the seal. They're stealing the stamp.

"Code signing proves an artifact is unmodified and authentic, but it does not evaluate the security quality of the code itself." Minimus Security Research

Read that again. The signature tells you a file wasn't changed after it was signed. It says nothing about what was in the file when somebody signed it, or whether the person who signed it was actually authorized, or had been compromised, or was working for the wrong team entirely.

Where the Deepfake Part Comes In

So what does this have to do with deepfakes? Everything, actually, once you understand what a deepfake really is.

A deepfake isn't just a fake video. At its core, a deepfake is a forged trust signal. It's something that looks real, checks out under normal scrutiny, and bypasses the filter between "safe" and "not safe." A fake video of a CEO authorizing a wire transfer is a deepfake. A fake voice call from your "daughter" asking for emergency money is a deepfake. And a malicious software file carrying a legitimate-looking approval stamp from a stolen signing key? That's a deepfake too, just one aimed at machines and IT teams instead of grandparents.

Attackers figured this out. Rather than writing code so clever it sneaks past security checks on its own, they now target the keys and credentials that create those approval stamps. Developer laptops, the personal computers used by the people who build software, have become prime targets. Those machines hold the digital keys used to sign software releases. Steal the key, and you can sign anything you want. Your malware gets an official badge. The door swings open.

There's also a second layer: software attestations (formal signed statements that say, essentially, "we built this code in a secure way, here's the proof"). Companies increasingly require these as part of releasing software. If every step of building the software is documented and signed, the thinking goes, you can trust the final product. But, and this is the part that keeps security people up at night, if an attacker compromises the system before the documentation is created, the attestation is perfectly real. Perfectly signed. And perfectly wrong.

As Chainguard's research on software attestations makes clear: a digital signature proves that the attestation itself wasn't tampered with, but it doesn't prove the claims inside the attestation are true. The badge looks real. The stamp checks out. The building lets you in. Previously in this series: Your Face At The Border Doesnt Get Deleted It Gets Filed For.

Why Deepfake Laws Overlook Approval Workflow Threats

Here's what really makes this a "deepfake" problem and not just a plain old hacking problem: it exploits the way humans process trust.

When something looks official, we stop asking questions. That's not a character flaw, it's just how brains work. We've built entire systems around trust signals precisely because we can't verify every single thing ourselves. A red light means stop. A green checkmark means approved. A signed document means someone credible vouched for it. We rely on those shortcuts constantly, and mostly they work.

Attackers know this. A fake signature doesn't need to break cryptography, the math behind these seals is genuinely very strong. It only needs to fool the human or the automated workflow that sees a green checkmark and moves on. And as AppViewX's analysis of digital signatures and deepfakes points out, the gap between "cryptographically valid" and "actually trustworthy" is exactly where modern attackers operate.

Most organizations have no habit of checking why something was signed, or when the key was created, or whether anyone verified the signer's identity before issuing the key. The green checkmark appears, and the door opens. Same dynamic as someone handing over a very convincing fake ID, the bouncer checks that it scans, not whether the face matches.

The Fix Exists, But Almost Nobody Has Deployed It

Good news: smart people have been working on this. Systems like Sigstore Rekor, a kind of public record book for code-signing events, create a permanent, tamper-evident log of exactly who signed what, with which key, and when. Think of it like a security camera for the approval process itself, not just the badge. Microsoft's own signing transparency research describes using these append-only logs specifically to prevent forged approval records, if someone tries to backdate or alter a signing event, the permanent log catches it.

The catch? Most organizations haven't adopted this yet. As JFrog's research on software attestation at scale notes, manual verification breaks down the moment you're dealing with hundreds of software components, which every large organization is. Automation and transparency logs are the answer, but they require someone to decide they matter and budget accordingly. Many haven't. Up next: Your Face Is Being Scanned At The Grocery Store And Washingt.

So we're in an awkward middle period. The tools exist. The threat is real and growing. Adoption is uneven. And the gap in between is where attackers are currently operating very comfortably.

If you've ever looked at a document or a profile and wondered, "Is this actually what it says it is?", that question is now the most important question in software security too. The instinct to look past the badge and ask for the evidence trail is exactly right. It's what identity verification at its best actually does: doesn't trust the stamp, demands the full story behind it.

One genuinely useful thing to bring up at work: ask your IT team whether your company logs signing events, whether there's a record of who approved what and when, that someone can actually review. Not just "is there a signature?" but "is there an audit trail (a permanent record you can look back through) behind the signature?" If the answer is "we just check that the signature exists," that's worth knowing.

The deepfake conversation has been almost entirely about faces and voices, can you spot a fake video, can you tell if that voice on the phone is really your boss? Those questions matter. But the version of this problem aimed at the software your company runs every day is quieter, harder to spot with your own eyes, and carries consequences that go well beyond one person being fooled by one call.

The scariest deepfake isn't the one that looks a little off. It's the one that looks exactly right, and is stamped, signed, attested, and approved, all the way down.

What Digital Signature Certificates Actually Certify

A digital signature certificate is issued by a certificate authority, an organization whose whole job is to check that the entity asking for a signing certificate really is who it claims to be before handing over the credential. That certificate authority vouches for the identity behind the key, which is why a digital certificate carries weight in the first place. When you see a valid certificate on a piece of software, you're trusting the certificate authority's original identity check, not just the math behind the signature itself.

This matters because signature certificates can be issued correctly and still end up in the wrong hands later. A signing certificate is only as trustworthy as the security around the private key that goes with it. If that private key leaks off a developer laptop, anyone holding it can create new signatures that look exactly like the real thing, because cryptographically, they are the real thing.

How to Digitally Sign a File Without Faking Identity Assurance

Most people who digitally sign a document do it inside something like Adobe Acrobat, which walks you through selecting a signature, applying it, and locking the file so further edits are visible. That process is genuinely useful for everyday paperwork, and it gives real identity assurance for low-stakes situations like signing a lease or a form. Acrobat's signature tools aren't the problem here, the problem is assuming that same level of trust automatically scales up to software that runs on thousands of machines.

The gap is individual identity versus organizational identity. When you personally digitally sign something in Acrobat, you're vouching for yourself. When a company signs software, the signature is supposed to vouch for an entire secure process, code review, testing, and approval, not just one person clicking a button. Conflating the two is exactly how a stolen key becomes a company-wide problem instead of a personal one.

Digital Certificates, Signing Certificates, and Digital Seals Compared

It helps to separate three terms that get used loosely. Digital certificates are the credential itself, the file that ties a public key to a verified identity. Signing certificates are digital certificates specifically issued for the purpose of creating signatures on code or documents. Digital seals are a broader idea: any cryptographic mark meant to show a file or message came from a trusted source and wasn't altered.

None of these three things prove good intent. They prove origin and integrity, assuming the private key behind them was never stolen. That distinction, origin versus intent, is the entire reason attackers have shifted their effort toward stealing signing certificates instead of trying to defeat the cryptography that backs digital certificates and digital seals.

Why Electronic Signatures and Software Signing Aren't the Same Risk

Electronic signatures on everyday documents, like the ones people sign in Acrobat, usually carry lower stakes because a forged signature on one contract affects one deal. Software signing carries far higher stakes because one stolen signing certificate can approve malware that spreads to every machine trusting that same certificate authority. Both rely on the same underlying digital signature identity concept, but the blast radius is completely different.

That's part of why organizations that issue signing certificates for software tend to require more identity assurance up front than a typical Acrobat electronic signature does, including hardware-protected key storage and stricter certificate authority checks. It's also why losing control of a signing certificate is treated as a security emergency rather than a paperwork inconvenience.