When we talk about the constant threat of malware to your business, we’re usually talking about the risks associated with non-compliance, data loss, or business continuity concerns. However, internal application quality and the software supply chain are not often mentioned – probably because the risks are not clear.
Here you will learn how malware can affect the application and release quality, as well as related systems and processes, and how they can be improved.
Today’s malware risks
The threat of malware to supply chain assets is large and real; attacks have been seen in large-scale environments. Development, production, testing, and manufacturing environments are characterized by nuances that allow (1) new malware to enter, (2) existing malware to go undetected, and (3) software lifecycle disruption. For example, a build and test environment may be vulnerable to third-party infection, may be built with malicious third-party software components (code, certificates), and may lack package and certificate validation after build – all possible attack vectors.
Their production environment poses a greater risk.
For example, Operation ShadowHammer, an attack on a software supply chain that used ASUS Live Update software, may have gone undetected because the updates were signed with legitimate certificates. Vendor updates and package redistribution could provide additional opportunities for malware infiltration and go undetected.
Other potential malware threats include the use of open source components for software development. Sometimes attackers conduct coordinated attacks on the supply chain to replace a tool they think they need with something malicious. Sometimes it’s as simple as a typo, and you end up with not the SQL driver you were expecting, but a bug-based Bitcoin miner.
Room for risk leaves room for consequences. So how can you build the right controls into the software development lifecycle (SDLC) to ensure your applications don’t serve as attack vectors?
Traditional continuous integration (CI) tools to combat these malware threats are not very powerful in terms of threat detection. Most organizations use vulnerability scanning and antivirus software, but in many cases, new vulnerabilities and malware are not added to CVE databases and are blacklisted.
How can you streamline the process while focusing on detection and reaping the benefits? There are two specific areas of detection that are very useful:
1. scanning all compilation files and all dependencies.
2. Perform a static analysis and check files and certificates.
If you first disassemble and scan all compilation files and all dependencies, and analyze and identify all components, you can see the deepest parts of the application – for example, you can detect embedded objects and more easily detect threats. Remember the coin injection mentioned earlier? Imagine a third-party vendor upscales their version and you don’t have a rigorous installer review process. You could miss the coin finder and put all your customers at risk.
Second, when creating executables for installation, the certificate chain must ultimately be valid. Static analysis can provide metadata about the final result and signature, so you can analyze your detection strategy based on the golden image sent – and also based on the golden images that come through the door. Whenever something enters your supply chain, you need to subject it to static analysis. Equip your detection process with automated scanning processes to ensure you’re performing the right checks throughout the SDLC cycle.
Accelerated development, high quality
How does the introduction of automated static analysis help accelerate application development and quality? Think about your competition. If you produce and distribute (or receive and distribute) complex packages, the ability to scan them within a given timeframe becomes critical. In this day and age, with runtimes skyrocketing, everyone is looking for ways to analyze their software in the sandbox. However, if you can scan larger Docker images in seconds.
Leave a Comment