Start With the Runtime, Not the Filename
Modern malware is not limited to a native executable. A suspicious delivery may be a managed assembly, a shell or browser script, a package release, a container image, a server-side extension, a mobile bundle, or a WebAssembly module. The first defensive question is therefore not “Which family is this?” It is “What would interpret this artifact, and which capabilities would that environment grant?”
File extensions are hints, not proof. Record the detected format, runtime metadata, expected entry point, declared permissions, dependencies, publisher information, and the environment in which the artifact was found. Keep observations separate from conclusions. A compressed or minified script may be normal; a signed package may still be compromised; and an unfamiliar WebAssembly import is not automatically malicious.
A Cross-Runtime Evidence Map
| Artifact | Useful offline evidence | Questions for the defender |
|---|---|---|
| Managed code | Assembly identity, runtime target, imports, resources, signing metadata, and configuration | Does the capability set match the stated purpose and trusted build? |
| Scripts and server extensions | Interpreter, imports, encoded content, template boundaries, deployment path, and change history | Was this file expected, reviewed, and produced by the approved release process? |
| Packages | Manifest, lockfile, lifecycle declarations, dependency graph, publisher, integrity fields, SBOM, and registry provenance | Did the name, version, maintainer, source, or dependency graph change unexpectedly? |
| Container images | Manifest, digest, layer history, base image, user, entry point, exposed configuration, signatures, and attestations | Can the deployed digest be traced to a reviewed source revision and isolated build? |
| WebAssembly | Module sections, imports, exports, embedded names, host bindings, and expected digest | Which host capabilities can the module reach, and are those capabilities necessary? |
| Browser and mobile bundles | Permissions, update source, extension points, network destinations, signing identity, and store metadata | Are requested permissions proportional to the feature and consistent with the prior release? |
The strongest finding usually comes from a mismatch: a small formatting package declares an unexpected execution hook, an application image changes its base and user, or a browser extension requests a new high-impact permission. A mismatch deserves investigation, but it still needs provenance and behavioral evidence before it becomes a malware verdict.
Triage the Supply Chain Before Execution
Package and CI investigations begin with comparison. Compare the release manifest with the lockfile, the lockfile with the SBOM, the published digest with the deployed digest, and the provenance statement with the expected repository, builder, and source revision. Do this offline. Do not install the package, invoke a lifecycle hook, start the image, or run an unfamiliar build script merely to see what happens.
Look for unexplained maintainer changes, dependency confusion, a near-match package name, a source archive that does not reproduce the published artifact, mutable tags, unexpected files in a release, or a build that cannot be linked to its source. CI evidence also includes workflow changes, runner identity, secret access records, artifact upload records, signing events, and approval history. The course uses synthetic records only; learners never receive registry credentials, real CI tokens, or a functional malicious package.
Recognize Families Without Recreating Them
- Trojans and loaders: investigate a gap between the advertised purpose and declared capabilities, unexpected secondary content, or a release that no longer matches trusted provenance. Analysis stops at describing the evidence. The course does not build a loader or execute a second stage.
- Web shells: look for an unapproved server-side file, an unusual deployment path, unexplained interpreter activity in sanitized logs, and a change outside the release pipeline. Do not create a command-capable page.
- Cryptominers: correlate an unexplained executable or container layer with sustained resource use and synthetic pool-like network evidence. High CPU by itself is not enough.
- Browser and mobile threats: compare permission changes, signing identity, update origin, local storage access, and sanitized network metadata. Never inspect a learner's real browser profile or device backup.
- Cloud and container threats: relate image provenance, workload identity, deployment audit records, runtime policy, and unexpected egress. Do not assume an image is safe because it came from an internal registry.
These labels overlap. A trojanized package could introduce a miner, a web shell could act as a backdoor, and a container could be only the delivery vehicle. Report the observable behavior and confidence before applying a family label.
Controls Developers Can Own
Preventive controls should make the trusted path narrow and the evidence path rich. Pin dependencies by immutable identifier, verify integrity, separate build and release authority, use isolated short-lived builders, protect signing operations, generate and retain provenance, scan the resolved artifact rather than only its source, and keep an inventory of deployed digests. Limit package lifecycle execution and container privileges to what the product actually needs.
A mature response is not “ban every script.” It is to define which scripts are allowed, who can change them, where they may run, what they may access, and which logs prove that policy was followed. That turns supply-chain security from a one-time scanner result into an engineering system.
Suggested Study Plan (6 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.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 1h 26m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1h 11m | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1h 11m | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 1h 15m | A release-triage worksheet containing an artifact inventory, five evidence-backed observations, alternative explanations, a disposition, and a developer-control plan. |
| Knowledge check and review | 57 minutes | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: A package has a familiar name and a valid registry checksum, but its publisher and lifecycle declarations changed. Is the checksum enough to approve it?
Reveal the defensive reasoning
No. The checksum proves that the downloaded bytes match the registry record; it does not prove that the publisher, source, or behavior is trusted. Quarantine the artifact, compare provenance and ownership history, review the declared capability change, and use approved offline evidence. Do not install it to answer the question.
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.