Skip to main content

Malware detection policies

Malware detection policies are a group of software quality policies used by the Spectra Assure platform to help you improve the overall software package security.


These policies are used during software package analysis to check your code and inform you if any of the built-in validation rules are violated. Specifically, malware detection policies focus on identifying malicious and suspicious software components to prevent threats from reaching production.

In the Spectra Assure SAFE report, these policy violations can be found in the Malware Detection issue category and cause risk in the SAFE Assessment Malware category.

Malicious components are parts of software found by malware detection methods and marked by classification technologies as exhibiting harmful behavior. On the other hand, components classified as suspicious are possible novel malicious threats that may be caught by proactive detections employed by advanced heuristics. They need to be reviewed by security teams, but their frequency is low.

Developers, release managers, and software publishers will benefit the most from the guidance provided by these policies. When Spectra Assure products detect malicious or suspicious components in a software package, the affected files are highlighted in the analysis report. Development teams can then apply the remediation advice for each particular policy to resolve detected issues.

Policies in this category​

Malware detection policies cover the following:

  • Malicious and suspicious files detected by ReversingLabs malware detection algorithms and threat researchers
  • Malicious and suspicious files detected through file reputation sources and third-party scanners
  • Living off the Land binaries (LOLBins) and potentially unwanted applications (PUAs)
  • Suspicious file formats and malformed file format structures
Show/hide all policies

Security challenges and practices​

Software development is challenging enough on its own; a process with numerous moving parts where it's easy to inadvertently introduce mistakes that may result in a dysfunctional or compromised product. Developing secure software requires overcoming another challenge: how to detect and avoid code created with the purpose to harm.

As codebases and development teams grow, software development processes become increasingly complex. Gradually, there is an increasing number of links in the software supply chain to manage, and more people involved at different stages with varying permissions to access and modify business-critical systems. Software supply chain security is not just about protecting the final software package you ship from malware. You also need to make sure the developers are aware of and protected from potentially harmful tools throughout the development process.

External dependencies and libraries are a perfect example of resources that software developers rely on constantly. After all, it makes sense to reuse existing solutions and speed up development instead of reinventing the wheel in-house. Those external resources can be proprietary or open source, and come from sources that may not always be trustworthy. Of course, before integrating any third-party components, developers are expected to perform due diligence and ensure the components are safe to use. However, in practice, trust is often given implicitly based on previous experience or current technology trends, instead of verifying and monitoring every component.

Open source components are particularly risky because of their unpredictable lifecycle patterns. They proliferate fast and change even faster, while proper security auditing requires resources that open source maintainers might not always have access to. Open source code, with all its software freedoms, breeds innovative, practical, and useful solutions. It's also a perfect breeding ground for malware.

Malicious actors understand that classic malware campaign tricks won't necessarily cut it when designing software supply chain threats. Instead, they learn and continuously apply new, increasingly subtle tactics to compromise the software development lifecycle at every possible stage. The accessible nature of open source communities enables attackers to infiltrate projects and sneak in all kinds of code changes under the guise of honest contributions. Over time, they learn to blend in with the codebase, mimicking the coding style and naming standards, which increases the chance of malicious changes flying under the radar and staying undetected longer.

Threat actors may also resurrect abandoned open source projects and push out new versions, or resort to typosquatting attacks on popular open source packages. While inserting known malware into open source dependencies is still a fairly common approach, more sophisticated methods have also been observed in the wild. They usually involve some kind of malicious tampering with software behaviors or permissions. Once those changes are digitally signed and distributed as a software package, no amount of signature or hash checking will indicate that anything is wrong.

Another approach is hiding malware in images and documents, or otherwise modifying file format structure to avoid detection. Similarly, to evade dynamic application security testing (DAST) tools, attackers may design malicious software components to execute their payloads only after they had been imported into or used by legitimate applications, instead of immediately after they're installed. Generally, any kind of hidden (obfuscated) functionality and unexplained communication with third-party infrastructure is a reasonable indicator that the software component may not be as safe as it seems.

The ability to recognize dangerous behavior changes and identify suspicious actions and anomalies in software components can significantly bolster your software supply chain security. Unfortunately, many modern malware scanners and endpoint security solutions fail to provide that level of insight. Some threats are buried so deep that anti-malware engines are unable to detect them, which leads to incomplete results. Software Bill of Materials (SBOM) generators can reveal the dependency hierarchy, but they aren't all equally comprehensive. Besides, there are ways to add components to code, containers, installers or commercial libraries without declaring them on build or package manifests, which ultimately affects the SBOM transparency.

Additionally, anti-malware engines tend to have file size limits for effective scanning, which makes scanning large software binaries and container images unfeasible. General-purpose malware detection tools aren't built to monitor third-party software updates, and they cannot identify active threats and tampering in codebases, or locate suspicious behaviors. In fact, detecting behavioral changes may be the key gap that most tools aren't yet able to bridge. Such changes are demonstrably difficult to spot even with code reviews and vulnerability scans, especially when attackers mask their malicious code by imitating legitimate developers.

In other words, detecting malware in the software supply chain requires not only deep analysis, but also a thorough understanding of the software development cycle and all its intricacies. Generic malware detection solutions will be a lot less successful in detecting such issues than a product built by developers for developers.

The Spectra Assure platform is exactly that type of product. It provides more accurate malware detection than signature-based and antivirus scanning methods. Moreover, its ability to track software evolution across subsequent versions means that Spectra Assure can detect advanced software supply chain attacks. It's all thanks to its static analysis engine and up-to-date threat classification combined with curated threat intelligence from the largest commercial repository of goodware and malware.

When you analyze a malicious software package with Spectra Assure, its unique file decomposition approach exposes malicious code hiding in deep layers of complex component and dependency hierarchies. Indicators, behaviors, and other metadata extracted during analysis reveal the full lifecycle of a software supply chain attack.