Malware defense is not only an endpoint-product decision. Application architecture determines whether a compromised dependency, update channel, plugin, token, build worker, or parser becomes a small contained failure or a widespread customer incident. Developers cannot predict every future technique, but they can make trust explicit, reduce privilege, preserve evidence, and build recovery into the product.
The strongest design asks four questions at every boundary: Can we prevent an unauthorized change? If prevention fails, how far can it spread? Which evidence will explain it? How will customers recover through a channel that remains trustworthy?
Map the source-to-runtime trust path
| Stage | Failure to design for | Control | Evidence retained |
|---|---|---|---|
| Source and review | Unauthorized code or workflow change | Protected changes, reviewed ownership, signed identity, and narrow administrator roles | Commit, reviewer, policy result, branch event, and exception record |
| Dependencies | Unexpected publisher, version, component, or install behavior | Approved sources, immutable resolution, integrity verification, lifecycle restrictions, and review | Manifest, lockfile, SBOM, registry metadata, and decision history |
| Build | Mutable runner, input substitution, or untrusted build result | Isolated short-lived builders, controlled inputs, least privilege, and SLSA provenance | Builder identity, source revision, parameters, materials, subject digest, and attestation |
| Signing and promotion | Valid signature from an unauthorized workflow or identity | Separate signing authority, policy verification, independent approval, and immutable promotion | Signer authorization, policy result, artifact digest, release approval, and transparency record where used |
| Update and install | Wrong product, channel, version, metadata, or excessive privilege | Verified metadata, staged download, pre-install checks, narrow privileged helper, and rollback policy | Update decision, verification result, installed digest, health result, and rollback event |
| Runtime and plugins | Untrusted input or extension inherits the application's authority | Capability-based interfaces, sandboxing, isolated storage, workload identity, and kill switches | Plugin identity, granted capability, process lineage, sensitive operation, and policy decision |
Draw this path before buying another scanner. Mark who can change each stage, which identity crosses it, and which verifier is independent of the artifact being checked. A control owned by the same compromised workflow may produce convincing but untrustworthy evidence.
Use prevent, limit, observe, and recover as a design review
- Prevent: Which unauthorized source, dependency, builder, signer, update, or plugin change should policy reject before runtime?
- Limit: If that policy fails, which process, identity, filesystem path, network destination, customer, or release channel is exposed?
- Observe: Which stable event proves the decision, identity, artifact, version, result, and failure? Can the event be recorded without secrets?
- Recover: Which known-good source and independent channel can revoke, rebuild, restore, communicate, and roll back safely?
Apply the questions to features, not only infrastructure. An image parser, IDE extension, document converter, package plugin, or updater may process untrusted input with broad authority. A safe default should not depend on every user discovering an advanced security option.
Safe worked scenario: redesign a fictional updater
A fictional desktop developer tool checks for updates inside its main process, downloads a package, verifies only a signature, and then asks for administrator access to install it. The same build workflow can alter source, produce the artifact, and invoke signing. Plugins run inside the main process and share the user's organization token. Nothing in this scenario is executable; it is an architecture review using diagrams and inert metadata.
The first finding is not “the signature is weak.” A signature can prove that bytes are associated with a signing identity and detect later modification under that scheme. The missing control is authorization across the complete path. The redesign separates update checking, download, metadata and provenance verification, staging, a narrow privileged installation helper, health checks, and rollback. Promotion policy verifies source revision, approved builder, subject digest, signer authorization, SBOM binding, channel, and version.
Plugins move behind a constrained interface with explicit capabilities and isolated storage. The user sees permission changes before approval. The product records plugin identity and sensitive operations without logging tokens. A server-side kill switch can disable a bad plugin identity, while the local application still has a documented offline recovery path. The team tests a revoked signer, unavailable update service, failed health check, and rollback to a verified supported release.
Make software origin verifiable
An SBOM inventories components and relationships for a defined artifact. Provenance describes where and how an artifact was built. A signature binds content to a signing identity. Policy decides whether that identity, builder, source, and workflow are authorized for this release. These controls answer different questions and should be bound to the same immutable artifact digest.
The package and container triage module shows how manifests, lockfiles, image history, SBOMs, and provenance support offline review. The secure development module translates the NIST Secure Software Development Framework and SLSA 1.2 into an owned product backlog.
Verification must happen at consumption. Producing an SBOM or provenance statement that nobody checks creates inventory, not protection. Store the verifier policy outside the artifact, record results, and provide an expiring exception path with an owner and compensating control.
Reduce blast radius before detection
| Risky convenience | Safer production alternative |
|---|---|
| Updater always runs with administrator authority | Unprivileged checking and verification with a narrow, short-lived installation helper |
| Plugin runs inside the host process | Constrained out-of-process service or declarative extension with explicit capabilities |
| Application and CI share long-lived secrets | Workload-specific short-lived identity, secret isolation, and audience-restricted authorization |
| Mutable image tag or dependency range reaches production | Reviewed immutable digest or lockfile plus provenance and promotion policy |
| Security telemetry records full commands or payloads | Structured events for identity, operation, object category, result, and correlation with minimization |
Least privilege is a product requirement, not a one-time infrastructure setting. Review filesystem, network, process, cloud, secret, device, and update capabilities. When broad authority is unavoidable, isolate it behind a small interface with stronger verification, observability, and recovery.
Build incident readiness into the product
Maintain an inventory of released and deployed digests, owners, dependencies, signers, and update channels. Define how to pause promotion, revoke a release or identity, disable a plugin, notify affected customers, rebuild from known-good source, restore data, verify telemetry, and reopen in stages. Exercise these paths before an emergency.
Recovery is not merely “install the old version.” Prevent unsafe downgrade, preserve compatible data migrations, verify the rollback artifact, and keep a recovery channel independent enough to work when the primary updater is unavailable or untrusted. The synthetic developer-tool capstone connects this design to evidence, detections, containment, reporting, and staged recovery.
Limits and honest trade-offs
No architecture makes compromise impossible. Strong provenance does not prove source correctness or safe dependencies. A valid signature does not prove the signer was authorized. Sandboxing adds complexity and may still expose intentionally granted capabilities. Strict update policy can delay an urgent fix if the emergency path was never designed. Telemetry improves response but adds privacy, cost, and retention obligations.
Record these trade-offs explicitly. Define owners, failure modes, exceptions, and tests. Do not weaken customer security silently when a verification service is down. Choose a fail-safe behavior appropriate to product risk and provide a supported recovery path.
Continue with supply-chain and platform practice
Read Software Supply Chain Security Explained, use the DevSecOps cheatsheet, and practice release decisions in the supply-chain defense game. The secure CI/CD module adds cloud-native pipeline controls.
Primary sources are NIST SP 800-218, the Secure Software Development Framework, the approved SLSA 1.2 specification, and CISA Secure by Design. Use them as outcome frameworks, then implement controls that fit the actual trust path and can be verified in production.