Building Malware-Resistant Software

Design the Trust Path

Software reaches a user through a chain of trust decisions: contributor identity, source review, dependency resolution, build workers, release approval, artifact storage, update metadata, installer privilege, plugin loading, runtime permissions, telemetry, and recovery. An attacker needs only one weak boundary; a developer needs a coherent policy across the path.

Draw the path before selecting tools. Mark who can change source, workflow, dependency policy, build inputs, signing configuration, release metadata, and update channels. Mark where untrusted data enters and where a component crosses into greater privilege. Record which evidence a verifier can check independently.

Secure by design means the safe path is the default path. Users should not need hidden flags or expert knowledge to verify an update, disable an unnecessary plugin, recover a previous version, or operate the product with limited privilege.

Use the SSDF as an Engineering Backlog

NIST SP 800-218 organizes secure software development into four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. Use the SSDF to find gaps in responsibilities, environments, source protection, component review, secure design, verification, release integrity, vulnerability intake, remediation, and lessons learned.

The SSDF is outcome-oriented. Translate each selected practice into an owner, repository or platform control, evidence, review cadence, and exception process. A policy document without automated guardrails and verifiable evidence will drift from daily engineering behavior.

Prioritize by product risk. A self-updating developer tool with organization credentials needs stronger release and runtime boundaries than a static documentation generator. Both still need provenance, dependency awareness, review, and a supported vulnerability-reporting path.

Signatures, Provenance, and SLSA 1.2

A signature can bind an artifact to a signing identity and reveal later modification. It does not prove the source was reviewed, the build was isolated, the dependencies were safe, or the signer was authorized for that release. Policy must decide which identities, workflows, repositories, and environments are trusted.

Provenance describes how an artifact was produced. SLSA 1.2 provides tracks and levels for improving supply-chain integrity, including a Build track focused on provenance and protections around the build process. Verify provenance against policy before promotion: expected source, immutable revision, approved builder identity, required parameters, and subject digest.

Keep signing authority separate from ordinary developer workstations. Protect release workflows with reviewed configuration, short-lived identity where supported, restricted permissions, independent approval for sensitive changes, and a tested response for key or identity compromise. Verification should fail safely without making recovery impossible.

SBOMs Support Decisions, Not Verdicts

A software bill of materials inventories components and relationships for a defined artifact. It can help answer which releases contain an affected component, where a transitive dependency entered, and which teams need to investigate. Common formats include SPDX and CycloneDX.

An SBOM does not prove a component was untampered, reachable, vulnerable in the deployed configuration, or absent when the generator had incomplete visibility. Record the generator, format version, artifact digest, completeness scope, and creation time. Sign or bind the SBOM to the release and verify that relationship.

Combine SBOM inventory with provenance, vulnerability intelligence, reachability or exposure context, runtime observations, and owner decisions. Do not publish internal component inventories without reviewing the security and licensing implications.

Least Privilege, Updates, Plugins, and Rollback

Installers and updaters are attractive trust boundaries because they often write executable content and request high privilege. Separate update checking, download, verification, staging, and privileged installation. Verify metadata and artifact identity before privilege is granted. Bind an update to the expected product, channel, version, and rollback policy.

Plugins should have explicit capabilities, isolated storage, version constraints, trusted distribution policy, and a kill switch. Loading arbitrary code into the main process gives a plugin all of the host application's authority. Where possible, move extensions into a constrained process or declarative interface and require user-visible permission changes.

Rollback must be safe as well as available. Prevent silent downgrade to a release with known security defects, preserve compatible data migrations, verify the rollback artifact, and keep a recovery channel independent from the primary updater. Build incident readiness into the product: release inventory, feature kill switches, trustworthy audit events, revocation policy, and an owned communication path.

Suggested Study Plan (4 hours)

The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.

Evidence Check

Question: A release has a valid signature and an SBOM. Does that prove it is safe to install?

Primary References

Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.

• NIST SP 800-218: Secure Software Development Framework
• SLSA specification version 1.2
• SPDX specifications
• CycloneDX specification overview
• CISA Secure by Design