Code Exposure: The Vulnerabilities in Your Code & Where They Originate
Typical software applications are comprised of two types of code: custom code created by your internal development teams, and third-party code – often open source – created outside the organization. Until about 10 to 15 years ago, almost all software was custom code, and every line of software was created and tested by in-house software teams. Third-party code from vendors, and in particular open-source software, wasn’t trusted. Regardless of the source, there are vulnerabilities in nearly every piece of code – which we at Checkmarx call, code exposure.
Software security solutions that include application security testing (AST) manage and measure your overall Software Exposure, which helps you accurately understand and significantly reduce your organization’s business risk. One component of software exposure includes the concept of code exposure as shown in the graphic below. This concept raises the question of, “Have we identified critical vulnerabilities in our software – both custom code & open source?”
What Are Vulnerabilities?
Vulnerabilities are weaknesses in software that can often be exploited by threat actors. Most vulnerabilities occur during the design and coding phase of the Software Development Life Cycle (SDLC). These vulnerabilities are the result of several factors to include design errors, coding errors, and the use of open-source components with known vulnerabilities. Another significant contributing factor to developers introducing vulnerabilities is due to code complexity.
Organizations with very large software applications typically do not have one person on staff that understands the entire code base, which can contribute to the propagation of security issues throughout a code base.
Vulnerabilities Due to Coding Errors
Software developers work from a specification describing what the software is intended to do (for example, when button A is pressed, display Account Information). Developers use functional requirements as the blueprint for their work. If a functional requirement doesn’t perform as specified, a functional “bug” is recorded.
Security bugs or defects can occur when features aren’t implemented properly. For example, when button A is pressed, information on all accounts is displayed. Or the feature works, but it can be manipulated by threat actors to gain access to privileged information. Security must account for unforeseen misuse cases that cause the application to “break”, or otherwise perform in unintended ways.
The security of software is usually not part of the functional specification, and just having a requirement that the software be “secure” doesn’t count. Software developers have traditionally been measured on a functional basis. If they delivered features on time, they were doing their jobs right. Security was never considered until about 20 years ago, and secure coding is still rarely taught in computer science programs.
Lack of Focus on Security, Leads to Code Exposure
One source of code exposure is mistakes or weaknesses created by developers in custom software when they’re writing code. These weaknesses are often derived from poor coding behaviors, habits, and policies, or they are due to an ever-changing threat landscape or characteristics of various coding languages. Threat actors focus their efforts on finding these weaknesses and exploiting them, often to their financial benefit. The most common weaknesses (or software errors) are enumerated in the OWASP Top 10 and the SANS Top 25.
Vulnerabilities from Third-Party Components
The adoption of open-source components by software development teams dramatically changed the software industry. Instead of building all software “from scratch”, organizations use open-source components to provide common or repetitive features and functionalities. This limits the use of custom code to proprietary features and functionality.
As a result, developers spend their time on key differentiators, rather than recreating common features. The adoption of open source by nearly all industries has fueled increases in open-source development. Many large organizations, such as Microsoft, have embraced open source, and millions of open-source projects are available to developers to both use, and contribute to.
Open-source software is still software and it’s exposed to coding errors that can result in security vulnerabilities. Large numbers of newly discovered vulnerabilities are disclosed in open-source software every year. These vulnerabilities are typically reported in a responsible manner, accompanied by a patch or updated version that fixes the vulnerability, making remediation of vulnerable components relatively easy.
Remediating Vulnerable Components
It’s not always simple to remediate “the usage” of a vulnerable open-source component, however. First, you must have visibility of where open-source components are used. Unfortunately, many organizations don’t track their usage of open source – or they track them in a static, outdated spreadsheet. The average application includes hundreds of unique open-source components, and developers download and keep those components in their workspaces for years.
As these components age, the chance that vulnerabilities have already been discovered and disclosed in them increases. With hundreds of poorly tracked components, and lots of new vulnerabilities each year, many organizations are exposed to potential exploitation. Attackers are well aware that these open-source components are often poorly tracked and maintained.
Identifying Code Exposure for Custom Code
Fortunately, there are solutions that help identify code exposure. Start by analyzing the software your organization creates internally, and choose a complete application security testing solution that integrates with Continuous Integration (CI) servers as well as the developers’ integrated development environment (IDE). Static Application Security Testing (SAST) and Integrated Application Security Testing (IAST) solutions are a must have. These solutions help you identify coding errors in custom code so you can find vulnerabilities early in the SDLC. It’s also important to configure your security solution to test for specific types of weaknesses or errors, such as those listed in the OWASP Top 10 or SANS Top 25. Of course, those aren’t the only vulnerabilities to worry about, so it’s helpful to be able to test more broadly in all cases.
Identify Code Exposure in Third-Party Code
Today, the average application is mostly open source. Software composition analysis demonstrates that today’s applications are comprised of more than 80% of open-source components within the code base. The adoption of Linux as an enterprise-class operating system, Java as primary development language, and Apache Struts as an MVC framework have increased confidence in open-source components.
Since open-source components have become the building blocks for modern applications, identifying code exposure in third-party components has become an essential part of any software security program. You need a solution that mitigates code exposure from third-party components by scanning builds to identify all open-source components used. Look for solutions that provides a list of any publicly reported vulnerabilities in those components, accompanied by remediation advice for using updated versions or patches for those vulnerabilities. It’s essential that your software security solutions are integrated into build processes, then reviewed and acted upon with every build.
Resolve Code Exposure
Incorporate application security testing (AST) solutions throughout your SDLC to manage risks inherent to code exposure. Here are some key software security solutions that can help your team resolve code exposure:
Static Application Security Testing
What to look for: ability to automatically scan uncompiled/unbuilt code and identify security vulnerabilities in the most prevalent coding languages.
Interactive Application Security Testing
What to look for: ability to continuously monitor application behavior and find vulnerabilities that can only be detected on a running application.
Open Source Analysis
What to look for: ability to enforce open source analysis as part of the SDLC and manage open-source components while being able to ensure that vulnerable components are removed or replaced before they become a problem.
Developer Software Security Education
What to look for: an interactive, engaging software security training platform integrated into the development environment, sharpening the skills developers need to avoid security issues, fix vulnerabilities, and write secure code.
Professional & Managed Services
What to look for: a trusted team of advisors who can help development organizations transform their DevOps initiatives by adding security throughout their SDLC.
With the information these software security solutions provide, your team can prioritize issues properly and resolve them in a timely manner.
Unify your software security into a single, holistic platform to manage your software exposure. Learn how here.