On March 21, the Biden administration directed US companies to “harden your cyber defenses immediately.” The Briefing Room Fact Sheet warns that Russia may soon engage in “malicious cyber activity against the United States” in response to the economic sanctions imposed since it invaded Ukraine.
With these new federal guidelines for application security, the White House urged software developers to deploy “modern tools that can detect known and potential vulnerabilities” in their custom and open-source software (OSS). Further, companies must ensure that critical vulnerability exposures (CVEs) are remediated before applications are released.
This preventative approach to app sec significantly reduces the risks of flawed software being used as an attack vector into an organization. It also has downstream benefits, reducing the burden on security operations center teams to investigate and respond to attacks and to decrease or eliminate potential financial, regulatory, and reputational risks of experiencing a major security breach.
For many organizations, these recommendations are not new. In fact, they’re best practices. But with hundreds or thousands of vulnerabilities, there is simply not enough time or development resources. So the real challenge is figuring out which issues are the most critical to fix first.
The following strategies will help allow developers and app sec teams to meet these federal guidelines efficiently and confidently.
A holistic approach to CVE detection
Now more than ever, developers need to have the ability to identify OSS and custom code vulnerabilities, insecure coding practices, and flawed technical and business logic in a single, fast, and automated scan.
Developers need to take a holistic approach when tracing the flow of data through an application or service—including every security transform and sanitization step—from source to sink. The accuracy, completeness, and speed will be important to run multiple scans each week rather than every few months or when an application is about to go into production.
It’s not unusual for a scan to detect thousands of OSS vulnerabilities, but most have no security impact and should be assigned a low priority. These unreachable, or un-attackable, vulnerabilities amount to false-positive detections that could be safely ignored.
Developer time is precious, so mitigation efforts must always focus on real, significant risks. Developers need to prioritize remediations by determining whether a CVE in an OSS application is actually “attackable.” This requires an assessment of whether the code has the potential to lead attackers from insecure inputs directly to open-source CVEs, based on four criteria:
- Is the package that contains the CVE loaded along with the app?
- Is it in use?
- Is the CVE reachable via untrusted input?
- Are options available to fix it?
A finding that is “attackable” is likely to be discovered and exploited, exposing the organization to significant risks of cyberattacks. Consequently, unless there are offsetting factors, vulnerabilities flagged as attackable should always be remediated first.
Intelligent remediation at scale
CVEs that are “attackable” should be investigated and remediated. Some risks can be mitigated simply by upgrading the vulnerable package. However, this is not always effective, since upgrades may not be available when needed or may require significant rewrites that affect multiple applications across the entire codebase.
Often, it’s necessary to correct the flaw or sanitize the data flow manually. This can be challenging.
Developers can spend many unproductive hours searching GitHub and other sites for relevant remediation code examples. Many turn out to be flawed themselves, out of date, ineffective, or difficult to adapt to their needs.
By scanning frequently, developers help reduce app sec risks without compromising software delivery timelines. This is especially helpful for developers with limited knowledge of secure coding practices. Once the fix is applied, a follow-up scan can confirm that the bug has been mitigated.
Understand what’s in your apps
Another key aspect of the Biden administration’s fact sheet is the need to have visibility into the makeup of your applications. This amounts to an inventory of what makes up the applications’ code, or what’s commonly known as a software bill of materials (SBOM). The tools employed to scan applications for vulnerabilities can also help you uncover the components and libraries used in applications.
This understanding can help your organization not only defend itself against state-sponsored attackers, but also be prepared for the next widespread zero-day vulnerability, such as the Log4Shell vulnerability in December 2021.
Log4Shell affected the open-source Apache Log4j logging framework, which was used in millions of custom-built and off-the-shelf software applications. When the vulnerability was disclosed, it sent enterprises around the world into a mad dash to understand if they were affected and, if so, implement remediation efforts to protect against attack.
Implementing the four-step, holistic approach explained above can make easy work of understanding which OSS libraries and components are used in your applications, allowing you to easily answer the question of whether you need to be concerned when the next zero-day vulnerability becomes known.
Key takeaways
The White House urged companies to execute many steps with urgency in order to meet the new federal guidelines to help protect against cyber attacks. If companies can effectively implement the suggested steps, they will receive many benefits, which include:
- Reducing organizational risks and rework time by identifying security issues early in the coding process when remediation is most easily accomplished
- Prioritizing remediation efforts based on the likelihood that CVEs will be discovered and exploited
- Accelerating CVE remediation by providing examples and code relevant to the specific application, operating environment, and organizational risk profile
- Streamlining collaboration among DevSecOps teams
- Providing decision makers with business justifications for mitigating CVEs
- Answering users’ and executives’ questions about new and emerging vulnerabilities and how they affect business applications
One of the most important steps outlined by the White House is to continuously look for and mitigate threats in applications by deploying modern tools. Implementing the key strategies listed above will help developers meet federal guidelines while preserving their productivity.