Infected Software is software that has been altered by malware or malicious code so it performs unintended actions. It may spread, steal data or weaken controls, so defenders should use trusted builds, verify signatures, scan artefacts and isolate any software showing unexpected behaviour.
What infected software means in practice
Infected software is not just “bad code”, it is legitimate software whose behaviour has been changed by malware or other malicious modification. The security issue is that users may still trust the name, publisher or location of the file even after its behaviour has been subverted.
That makes infected software especially dangerous in environments that rely on software provenance, internal distribution or repeated use of the same executables and packages. A trusted-looking application can become a delivery mechanism for data theft, control weakening or broader compromise.
How software infection changes the threat surface
Once software is infected, the attacker is no longer limited to a one-time intrusion. The altered program can execute in ordinary workflows, inherit user trust and blend into normal business activity. That gives malicious code a durable foothold and can turn routine execution into an attack path.
Infected software also complicates attribution and triage because defenders may first see symptoms such as unexpected network traffic, altered files, new child processes or policy bypasses rather than an obvious malware alert. The problem is not only the payload, but the fact that the software itself has become the carrier.
Common ways organisations discover infected software
Exposure is usually identified through software inventory, integrity verification, endpoint telemetry, file reputation checks or vendor alerts. A mismatch between a known-good build and what is actually running is often the clearest warning that an artefact has been altered.
Verification matters at every stage of the software lifecycle, from build and package distribution to deployment and update handling. Trusted build pipelines, signed artefacts and reproducible release practices reduce the chance that a compromised binary is accepted as legitimate.
For broader control coverage, defenders can align this work with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls for integrity, configuration management and auditing, and with SLSA when build provenance and artefact integrity are part of the concern.
Why containment and recovery matter after infection
Recovery is not complete when the malicious file is deleted. Organisations should assume the infected software may have been used to steal credentials, alter settings, create persistence or introduce additional payloads before it was detected.
That is why containment, revalidation and follow-up review are essential. If the compromised software interacted with privileged accounts, sessions, tokens or signing material, those identity artefacts may also need review or rotation as part of the response. Where software distribution or consumption occurs through APIs or shared services, OWASP API Security Top 10 is also useful for understanding how broken access controls or unsafe consumption can widen the blast radius.
After remediation, defenders should confirm that the replacement artefact is clean, that the original infection path has been closed and that no secondary persistence remains in adjacent systems or software repositories.
Risk and Threat Considerations
Infected software is risky because it inverts a core security assumption: code that appears trusted may actually be hostile. That can undermine confidentiality, integrity and operational control at the same time, especially when the infected artefact is widely deployed or frequently executed.
Failure mechanism: The malware modifies a legitimate program so the compromise travels with normal execution, which can evade shallow checks and persist until the artefact is replaced or rebuilt.
Impact: The altered software can steal data, weaken controls, assist lateral movement or reintroduce compromise after an initial cleanup, so the infected build becomes both the symptom and the attack vector.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, SLSA, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Directly addresses verifying software integrity and detecting tampering. |
| CM-5 — Access Restrictions for Change | Supports preventing unauthorised software modification and distribution changes. | |
| Recommendation — Validate software integrity and quarantine artefacts that fail trust checks. Restrict who can alter software packages, builds, and release artefacts. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Directly concerns build provenance and artefact integrity for software trust. |
| Recommendation — Adopt provenance controls so released software can be verified against trusted builds. | ||
| OWASP ASVS | V13 — Configuration | Covers secure configuration and integrity expectations for deployed software components. |
| Recommendation — Verify runtime configuration and reject unexpected changes that alter software behaviour. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Applies to discovering and managing software that may have been altered or replaced. |
| Recommendation — Maintain software inventory and remove unapproved or altered software quickly. | ||
Practitioner Guidance
Why practitioners should care: Treat infected software as both a malware event and a software integrity failure. The response should focus on whether the artefact can still be trusted anywhere in the environment, not just whether the visible malicious code has been removed.
What to watch for: Repeated hash mismatches, unsigned or unexpectedly signed updates, behaviour that changes after installation, and software that reaches out to unfamiliar destinations are all strong signals that the artefact itself may have been compromised.
Practitioner takeaway: The safest assumption is that any infected build, package or installer is untrustworthy until it is replaced from a verified source and the surrounding environment has been checked for secondary compromise.
Related resources from NHI Mgmt Group
- How should security teams handle exposed secrets in modern software pipelines?
- What is the difference between software supply chain risk and NHI risk?
- Why do leaked secrets need a different reporting path than ordinary software bugs?
- What is the difference between SaaS supply chain security and software supply chain security?