Application security is essential for every organization; however, many organizations ignore a large percentage of their application code when performing security analysis.  Almost every organization uses open-source code in their applications, and a failure to identify and correct vulnerabilities in these dependencies can leave the organization open to attack.

Most Applications Use Third-Party Code

When performing security assessments for their applications, many developers focus only on the code they have created.  However, this in-house code represents only the tip of the iceberg when it comes to the code actually included within an application.

Software development best practices support code reuse. When a development team needs to include new functionality in their code, it is typically faster to use an existing library that utilizes code written by a subject matter expert, rather than writing the code in-house. As a result, applications have dependencies on external code. In fact, 96% of enterprise codebases contain open source code, with an average of 298 open source components per codebase.[1]  However, 40% of organizations perform no security testing of open-source code within their organization or claim that they use zero open-source code.[2]

Third-Party Code Introduces New Vulnerabilities

Third-party code comes from a variety of different sources.  Some code is developed by major organizations, such as Oracle or Microsoft, while other code is created by individual contributors and posted on StackOverflow or Github, where developers find it and integrate it into a project.

Subsequently, some code is created and released without being subjected to strong review and security testing. Even code that originates from a reputable organization can contain vulnerabilities.

When using third-party dependencies, any vulnerabilities contained within third-party code can be inherited by the application. It is essential that organizations perform application security testing on their entire codebase, including code developed both in-house and by third parties.

Managing Open-Source Vulnerabilities Through Security Automation

Failing to identify and correct these vulnerabilities puts an organization at significant risk. In 2019, 60% of data breaches involved exploitation of an unpatched vulnerability.[3]  However, tight deadlines mean that many development teams sacrifice security testing for speed.  In fact, over half of companies have admitted to cutting cybersecurity measures in order to meet a deadline.[4]

Balancing developers’ need for speed and an organization’s need for security requires security automation. By integrating application security testing (AST) into the development teams continuous integration and testing workflows, vulnerabilities can be detected and remediated early in the process, where they have a minimal impact on release timelines and security.

How MorganFranklin Can Help

When transitioning from DevOps to DevSecOps and working to integrate security into development processes, it is important to choose the tools and techniques that best meet an organization’s needs. Static application security testing (SAST), dynamic application security testing (DAST), and interactive application security testing (IAST) all approach the same problem in very different ways.

As a result, SAST, DAST, and IAST all have their advantages and disadvantages, which can affect how well they integrate into development processes and provide the desired level of security. MorganFranklin consultants have extensive experience in a range of application security testing tools and can help with selection, deployment, and configuration of the right solution for your unique environment and use cases.



Let’s Work Together