It’s that time of year again: October is Cybersecurity Awareness Month. At the very least, it serves as an annual reminder to check your security posture, both at work and at home. But I figured that it also might be a good time to take a closer look at more specific topics over the course of the month. I will do my best to stay out of the weeds, but this is important for all of us to be aware of.
This week, I’m going to focus on application security. Why? According to Forrester in their State of Application Security 2022 report, software vulnerabilities are the top attack vector in today’s world. Between 70-90 percent of modern applications use open-source software, and depending on how you implement it, open source can be a source of issues. Many penetration testing tools include plug-ins that not only detect libraries you are using, but also identify the security vulnerabilities associated with them.
On a cyber security discussion panel last month I was asked, “When your development team has to get a release out the door in a very short amount of time, why is it that security is typically one of the first processes to be bypassed to help hit the deadline? What should we tell the development team when they ask us to bypass security?”
Great question, because it encompasses the perceived paradox that we cannot be secure and agile. As application security professionals, we need to help change the narrative. If we are consistently holding up the build process, then we will eventually be bypassed. However, if we think outside of the box, we can achieve a win/win. For example, consider leveraging automation to trigger the security scans when code is committed, and do it in a way that is non-blocking. In this way, by the time all of the build processes have completed and the application is ready for QA, the security scans can be delivered simultaneously, and their review should be part of the QA process.
In my previous role as an AppSec architect, my tagline was “Protect and Secure. Reduce Risk. Enable Innovation.” I believe if these concepts are embraced, all three can be achieved to deliver software securely at all times and keep innovation and software delivery on track. Even considering edge cases that may be time sensitive, a collaborative approach can generally lead to a near-term mitigation that still ensures secure delivery of the application. For example, if a vulnerability has been discovered and the release is time sensitive (think log4j), then other mitigation efforts could be used to help reduce the risk of the release. For example, a web application firewall or front-end protection like Cloudflare could be configured to provide near-term mitigation while the software release fix is packaged in the next release.
Finally, when I consider the major challenges of an application security program, I must address the need to identify and approve third-party libraries and applications. Supply chain issues are the number one risk according to CISOs in 2022, and what can be more critical than an application dependency to a compromised third-party component or library? There are several steps to take to improve your third-party risk posture, including leveraging third-party scanning and building an executive reporting process for visibility and support at the decision-maker level of your organization. There are also other technical controls that can be leveraged, such as ensuring your applications leverage a local copy of code libraries versus pointing to an external source that may have been compromised.
This is just a start, but hopefully it gets you thinking about how to better secure your CI/CD pipeline.
Learn more application security tips in our new white paper, “Top Tactics for AppSec Innovation.”