Cyberattacks are not a question of if an organization’s code will be targeted, but rather when.

In fact, 43% of all data breaches are the result of poor web application security (AppSec) — the leading cause by a wide margin. Given today’s landscape, organizations are hesitant to report attacks as they fear it could impact reputation, making it challenging to determine the speed at which cyber incidents occur. This also fuels the industry’s lack of transparency and accountability.

The underlying problem is that the software market, including the software supply chain, doesn’t encourage security. It’s extremely difficult to tell the difference between secure and insecure software, and therefore both producers and users cannot make informed decisions about risk. The market doesn’t incentivize producers to create secure code, and users must blindly trust software with the most important aspects of their lives and businesses.

Enterprises can break this cycle and do a better job of protecting their applications across the entire software development lifecycle so that they do not fall victim to a breach. Application security initiatives should ensure that 1) custom code has the right defenses and is free of vulnerabilities; 2) open-source libraries are safe; and 3) proper tools for attack detection, visibility and exploit prevention in production are in place. It is critical for organizations to master these three areas by leveraging DevSecOps techniques.

1) Eliminating vulnerabilities; securing custom code

As applications become increasingly complex and distributed, the effectiveness of traditional application security tools and processes has fallen behind in several critical areas — including eliminating vulnerabilities during software development and protecting applications in a production environment. This has led to vulnerabilities released within application code without detection, as well as security test results coming back riddled with false-positive results. In fact, this is exactly what happened for many organizations responding to the December 2021 Log4j vulnerability. Teams chased fixes for libraries that weren’t actually used by their applications and APIs, wasting time that could be better spent on vulnerabilities in active code.

President Biden’s Executive Order (EO) on Improving the Nation’s Cybersecurity directed the National Institute of Standards and Technology (NIST) to create a new minimum standard for application security testing. The new standard encourages a modern approach that embeds security testing directly into code for optimum visibility, continuous monitoring of application systems, and faster run time. 

Rather than relying on traditional static and dynamic scanning tools for vulnerability discovery, organizations should move to interactive application security testing (IAST) tools for automated detection and identification of security flaws and vulnerabilities from within applications. Accurate and real-time application security testing is a must — from traditional web applications, APIs, serverless functions and everything in between.

2) Securing open-source libraries

Another trend in the developer world is the increased adoption of open-source software (OSS), in which code is designed to be publicly accessible for use and modification. With this decentralized and collaborative way of coding, organizations find that it is often cheaper, provides more flexibility and opportunity for innovation, and allows full visibility into the code base.

However, the proliferation of open-source software and its use across the entire software supply chain comes at a cost. Applications that use OSS are a primary target for cybercriminals because once a vulnerability is discovered, adversaries can attack virtually any application built using that now-vulnerable OSS.

Security teams typically rely on software composition analysis (SCA) tools to understand where their code is most vulnerable. While SCA is designed to scan the OSS code base for vulnerabilities, developers and security teams need to be careful about using legacy SCA. Often, legacy SCA only scans at the repository level, meaning security teams might only be looking at dependencies used for testing, part of the platform, or part of their application server. They also will have no way to know if those libraries are actually even invoked by the application or API. These failings can produce overwhelming results leading to alert fatigue, cumbersome security test slow down, and ultimately, no incident response plans for zero-day exploits. Runtime SCA tools can identify the most imminent risks by flagging libraries invoked by the application and aggregate vulnerabilities to create a centralized view of cyber threats.

While OSS can meet the business need for speed, organizations must ensure their security and vulnerability management tools can address the risks that come with it.

3) Attack detection and exploit prevention

As a community, we need to continue to build transparency across the entire software development — lifecycle development and operations.

Fortunately, the Biden administration has been making steps to put AppSec on the right path with the Cybersecurity EO and the implementation standards from NIST — both of which are pushing transparency in the software marketplace with requirements for creating a Software Bill of Materials (SBOM) and minimum application security testing, as well as the creation of assurance cases and software security labels. Many other organizations are supporting these efforts, including the Open Web Application Security Project (OWASP) and the Defense Information Systems Agency (DISA).

The next step is to ensure that security teams have visibility into who is attacking applications and APIs, what attack vectors they are using, and which systems they are targeting. Unfortunately, application layer cyberattacks are largely invisible to perimeter defenses, like traditional firewalls and intrusion detection systems (IDSs). Modern application communications are simply too complex to be understood by a network device, so they tend to both overblock and underblock — creating operational chaos. In order to detect these attacks, cybersecurity teams need to understand the attack data the way the code does, not as it exists on a network. It’s how the data is used by code that matters.

Finally, application vulnerabilities are inevitable but fixing them immediately after discovery is not always possible or practical. Detecting and protecting against cyberattacks before vulnerabilities are even patched can help security teams focus on other critical tasks, rather than fixing every vulnerability as it’s discovered.

The traditional model of application security is no longer enough — organizations must look to implement the right tools to achieve successful DevSecOps and fight against inevitable code vulnerabilities. A modern application security program must have the right platform of solutions to enable development and security teams to work together effectively across an entire software portfolio and software lifecycle.