Almost a year after the world was disrupted by log4shell, Sonatype's Steve Poole, a long-time secure code promoter, sounded the alarm regarding the advancement of cyber attacks during his Devoxx talk. Cyberwarfare is a reality, and countries use cyberattacks to fight other countries. More than awareness, the talk aimed to provide developers with hope by revealing the tools we have at hand to fight this evil.
The cybercrime landscape is as dynamic as the whole technology sector. There are already classical threats like:
- Botnets that try to breach your systems
- Malicious actors hunting for your secrets
- Data ransomware
- Cryptocurrency miners trying to take advantage of your CPU cycles
Other threats have appeared on the horizon, aiming mostly to take advantage of the importance that open-source components have in the software supply chain. Among the most well-known attack vectors are fake packages released in code repositories or malware hidden in the build process all with the sole intention of hijacking open-source projects to gain stealth long-term control.
In addition to recommendations provided by the industry, the US Government's Executive Order on Improving the Nation’s Cybersecurity encourages engineers to take swift action to improve security in the software industry.
Secure the supply chain by providing provable evidence trails
Many scanning tools can give a false sense of confidence, as not everybody has access to the same quality and amount of data. Even with all the notoriety of log4shell, currently 33% of all the downloads from Maven Central are still acquiring a vulnerable version.
In order to improve this, we need to switch from relying just on scanning tools to components that provide a software bill of materials (SBOM) that are centrally signed, provable, and reproducible.
Improve the understanding of vulnerable projects
The best way to protect your project is to be aware of what you are getting when you are choosing an open source component. Even though there is no formal checklist, you can verify the following:
- Don’t choose an alpha, beta, milestone, or release candidate version
- Don’t upgrade to a vulnerable version
- Upgrade to a lower risk severity if your current version is vulnerable
- When a component is published twice in close succession, choose the later version
- Choose a migration path (from version to version) others have chosen
- Choose a version that the majority of the population is using
- If all the above are tied, choose the newest version
Automating the supply chain: no human involvement in the code-to-cloud journey
Besides producing reproducible builds (builds that give the same source code, environment and instructions will create bit-to-bit identical builds), there is also a need to be able to trace a software component back to its source. Efforts are being made to automate the digital signing and checking of software components.
Improve the education of the developers
At the end of the day, the software is created by developers, and improving their awareness and skills to write more secure code can only benefit the whole effort. Probably the most accessible resource available is OWASP’s Top 10 Web Application Security Risks.
In addition to this, readers can consult Linux Foundation’s training resources for cybersecurity.
In conclusion, whether you understand the risks of cybersecurity or you just want to comply with the US Executive Order to improve the nation’s cybersecurity, you set yourself on a journey for a more secure software ecosystem.
