Security plan for the software supply chain
5 best practices for securing the software supply chain
By Arne Jacobsen
providers on the subject
Attacks on the software supply chain and cloud-native applications are on the rise. Hackers smuggle malicious software packages or tools into the development process and place dangerous malicious code there, which is then used in unsuspecting companies.
(Image: thodonal – stock.adobe.com)
As more and more companies adopt cloud-native strategies, it is even more important to better understand and prepare for the risks in the software supply chain. The following best practice methods help here and can serve as the basis for a structured security plan:
1. Strengthen DevOps teams, promote DevSecOps culture
DevOps is essentially a never-ending process. The key to continued success in securing the development process is ensuring developers have clear, accurate, and actionable security information as part of a cohesive workflow. The “shift-left” approach to software and system testing should be used, with testing occurring much earlier in the development cycle.
In order to make the right decisions about which software packages or libraries to use at all times within this process, developers need to know the risks and know how to avoid them. Ideally, testing security within each step of the development process is easy and doesn’t limit developer productivity or creativity. But if it’s too complicated to test security, for example, or if builds are checked too late, insecure solutions will find their way into production.
Recommendations: It’s a good idea to set up feedback loops to provide development teams with clear information about security risks and advice on how to fix them. It is important to consider the established DevOps workflows – to increase the likelihood that security can be integrated into the standard processes.
2. Automate security controls
Security controls can be automated, making it easier for developers to comply. Quite a few security professionals have reservations about using automation because they fear losing control or creating too many conditions that hinder workflows. However, security and automation can go hand in hand if one has the appropriate tools and criteria to act as a representative of the security team in automated systems.
Equipped in this way, security checks can be easily automated and deliberately embedded in the CI pipeline. Thanks to the automation, companies can also carry out standardized workflows and at the end receive a detailed report on unusual, risky or even malicious behavior and artifacts that came to light during the analysis. The results of this analysis then go to anyone who needs that information to take appropriate action.
Recommendations: Establish effective policies and controls to enable secure automation. Care should be taken not to over-specificate or over-generalize the terms on which these policies will take effect. These policies should be designed with scalability in mind and clearly define the follow-up steps to be taken in the event of a condition failure.
3. Define risk tolerance and security standards
When developing policies and controls, it is important to involve all relevant stakeholders. First, those who assess security risks, second, those who identify policy non-compliance, third, those who need to remediate security risks, and fourth, those who are responsible for security in production environments. Together, these stakeholders should define security risk tolerance for the software artifacts moving through the pipeline to identify, prioritize, and remediate risks before they cause problems in production.
However, when considering the collection of artifacts, packages, and libraries that arrive through the software supply chain, this task can become very complicated. That’s because most companies give up some level of control to the supply chain in exchange for greater flexibility, scalability, or efficiency. Identifying risks may not be possible with traditional application security assessment methods for third-party resources, and fixing problems is not always a task that in-house development teams can handle. As such, risk tolerance and security standards for supply chain packages are likely to differ from those they have for custom code, for example.
Recommendations: Talking to the contributors and security officers is advisable. Questions to ask include, “How does the review process for risks in code compare to those coming through the supply chain?”, “What response and remediation steps are automated?”, and “Who is notified?”
When the software supply chain is involved, the answers to both of these questions may concern people outside of the team or organization. Resolution in these scenarios can only be accomplished through a lengthy process of notifying the vendor of an issue and may be subject to their SLAs for response.
4. Remove “trust” from the security strategy
Unwarranted trust regularly serves as an attack vector or entry point into an environment. While it is possible to provide vulnerability information to developers and integrate security testing into the software development life cycle and continuous integration/continuous delivery pipelines, the software supply chain introduces many additional potential vulnerabilities where these security procedures may not be applied or may be ineffective.
Recommendations: The organization should understand that a vendor may not approach software security with the same rigor and standards as their internal security, DevOps, and development teams. Needless to say, nobody wants to leave the security of their company in the hands of third parties and trust that they take security just as seriously.
Tip 5: Structure your safety plan
The four stages mentioned form a solid foundation for minimizing risks in the software supply chain for native cloud applications. But sooner or later you have to run the developed software. Of course, this should not be done in the production environment, but in a sandbox environment. In this test environment, a security solution must then be used that can detect malicious behavior that only occurs at runtime. When such behavior occurs, it is important to prevent the malicious artifacts from entering production.
Detected malicious or unusual activities must initiate a chain of response. It’s important to automate these responses as part of the build process or CI/CD pipeline whenever possible. This way everything is tested in pre-production without creating additional hurdles for security and DevOps teams or increasing the risk of missing a delivery deadline for unnecessary reasons.
Finally, SecOps and forensics should be supported by automatically classifying the detected behaviors according to standards such as the MITER-ATT@CK framework. In this way, the lessons learned can be integrated into the overall picture of an organization’s software security risk, so that one is not comparing the proverbial apples and pears when a security team is analyzing the risk profiles of cloud-native apps, legacy apps, internal software and commercial ones Technologies considered in their entirety.
Conclusion
To prevent attacks on the software supply chain and cloud-native infrastructures, organizations need modern security solutions with dynamic threat analysis and the right security approach, based on industry best practices.
These include empowering DevOps teams, fostering a DevSecOps culture overall, defining risk tolerance and security standards for the supply chain, automating security controls, and relinquishing security strategy. These fundamentals form the foundation of an effective software supply chain security plan that can secure the entire development process.
About the author: Arne Jacobsen is Director of Sales EMEA at Aqua Security.
(ID:49249092)
