\nSoftware security solutions that include application security<\/span> testing (AST) manage and measure your overall Software Exposure<\/em><\/strong>, which helps you accurately understand and significantly reduce your organization\u2019s business risk. One component of software exposure includes the concept of code exposure<\/em><\/strong> as shown in the graphic below. This concept raises the question of, \u201cHave we identified critical vulnerabilities<\/span> in our software \u2013 both custom code & open-source?\u201d
\n
![\"\"](\"https:\/\/checkmarx.com\/wp-content\/uploads\/2019\/07\/Blog-Code-Exposure-Graphic.png\")
<\/a><\/p>\nWhat Are Vulnerabilities?<\/h2>\n
Vulnerabilities are weaknesses in software that can often be exploited by threat actors. Most vulnerabilities<\/span> occur during the design and coding phase of the Software Development<\/span> Life Cycle (SDLC). These vulnerabilities<\/span> are the result of several factors to include design errors, coding errors, and the use of open source components with known vulnerabilities<\/span>. Another significant contributing factor to developers<\/span> introducing vulnerabilities<\/span> is due to code complexity.<\/em><\/strong> Software developers<\/span> work from a specification describing what the software is intended to do (for example, when button A is pressed, display Account<\/span> Information). Developers use functional requirements as the blueprint for their work. If a functional requirement doesn\u2019t perform as specified, a functional \u201cbug\u201d is recorded. One source of code exposure is mistakes or weaknesses created by developers<\/span> in custom software when they\u2019re 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<\/a> and the SANS Top 25<\/a>.<\/p>\n The adoption of open source components by software development<\/span> teams dramatically changed the software industry. Instead of building all software \u201cfrom scratch\u201d, 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. It\u2019s not always simple to remediate \u201cthe usage\u201d of a vulnerable open-source component, however. First, you must have visibility of where open-source components are used. Unfortunately, many organizations don\u2019t track their usage of open source \u2013 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. Fortunately, there are solutions that help identify code exposure. Start by analyzing the software your organization creates internally, and choose a complete application<\/span> security testing solution that integrates with Continuous Integration (CI) servers as well as the developers<\/span>\u2019 integrated development environment<\/span> (IDE). Static Application Security Testing (SAST) and Integrated Application<\/span> Security<\/span> Testing (IAST) solutions are a must have. These solutions help you identify coding errors in custom code so you can find vulnerabilities<\/span> early in the SDLC. It\u2019s 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\u2019t the only vulnerabilities<\/span> to worry about, so it\u2019s helpful to be able to test more broadly in all cases.<\/p>\n Today, the average application<\/span> is mostly open-source. Software composition analysis demonstrates that today\u2019s applications<\/span> 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<\/span> as primary development language, and Apache Struts as an MVC framework have increased confidence in open-source components. 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:<\/p>\n What to look for:<\/strong> ability to automatically scan uncompiled\/unbuilt code<\/a> and identify security vulnerabilities in the most prevalent coding languages.<\/p>\n What to look for:<\/strong> ability to continuously monitor application behavior and find vulnerabilities that can only be detected on a running application.<\/p>\n What to look for:<\/strong> ability to enforce open-source analysis<\/a> 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.<\/p>\n
\nOrganizations with very large software applications<\/span> 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.<\/p>\nVulnerabilities Due to Coding Errors<\/h2>\n
\nSecurity<\/span> bugs or defects can occur when features aren\u2019t implemented properly. For example, when button A is pressed, information on all<\/strong> accounts<\/span> is displayed. Or the feature works, but it can be manipulated by threat actors to gain access to privileged information. Security<\/span> must account<\/span> for unforeseen misuse cases that cause the application<\/span> to \u201cbreak\u201d, or otherwise perform in unintended ways.
\nThe security<\/span> of software is usually not part of the functional specification, and just having a requirement that the software be \u201csecure<\/span>\u201d doesn\u2019t count. Software developers<\/span> have traditionally been measured on a functional basis. If they delivered features on time, they were doing their jobs right. Security<\/span> was never considered until about 20 years ago, and secure coding is still rarely taught in computer science programs.<\/p>\nLack of Focus on Security, Leads to Code Exposure<\/h2>\n
Vulnerabilities from Third-Party Components<\/h2>\n
\nAs a result, developers<\/span> 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<\/a>, have embraced open-source, and millions of open source projects are available to developers<\/span> to both use, and contribute to.
\nOpen-source software is still software and it\u2019s exposed to coding errors that can result in security vulnerabilities<\/span>. Large numbers of newly discovered vulnerabilities<\/span> are disclosed in open-source software every year. These vulnerabilities<\/span> are typically reported in a responsible manner, accompanied by a patch or updated version that fixes the vulnerability<\/span>, making remediation of vulnerable components relatively easy.<\/p>\nRemediating Vulnerable Components<\/h2>\n
\nAs these components age, the chance that vulnerabilities<\/span> have already been discovered and disclosed in them increases. With hundreds of poorly tracked components, and lots of new vulnerabilities<\/span> each year, many organizations are exposed to potential exploitation. Attackers are well aware that these open-source components are often poorly tracked and maintained.<\/p>\nIdentifying Code Exposure for Custom Code<\/h2>\n
Identify Code Exposure in Third-Party Code<\/h2>\n
\nSince open-source components have become the building blocks for modern applications<\/span>, identifying code exposure in third-party components has become an essential part of any software security<\/span> 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<\/span> in those components, accompanied by remediation advice for using updated versions or patches for those vulnerabilities<\/span>. It\u2019s essential that your software security solutions are integrated into build processes, then reviewed and acted upon with every build.<\/p>\nResolve Code Exposure<\/h2>\n
Static Application Security Testing<\/h2>\n
Interactive Application Security Testing<\/h2>\n
Open-Source Analysis<\/h2>\n
Developer Software Security Education<\/h2>\n