Code Exposure: The Vulnerabilities in Your Code & Where They Originate

When people ask me if I can code, I often tell them I can write scripts and hello world applications instead of actual coding. In my opinion, writing an application with a positive use is a lot easier than writing an application that handles negative use cases. Compounded by the fact that most programmers that are real programmers don’t code from scratch like how I was trained but to use 3rd party libraries that automatically do the task for them.

Typical software applications are comprised of two types of code: custom code created by 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 our partner at Checkmarx calls, code exposure.

One component of software exposure includes the concept of code exposure as shown in the graph below. This concept raises the question, “Have we identified critical vulnerabilities in our software – both custom code & open source?”

Code Exposure

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.

While I do know how to write applications that work, I don’t have any practical experience to merge my work into other developers’ work, thankfully I have a team of experienced engineers to help me with that tasks and tools to help detect coding errors.

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 is “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.

I still remember back in my university days when I was doing my programming modules, the focus was on speed and processing of tasks instead of secure coding. Security was largely focused on SQL injections, prevention of intrusions and what would constitute a good encryption algorithm. Being in management for Netrust, I’m glad tools exists to help in this. I’ll explain a little more in the next section.

1. Identifying Code Exposure for Custom Code

Like I said previously, there are solutions that help identify code exposure. We start by analyzing the software our 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 useful. These solutions help identify coding errors in custom code so you can find vulnerabilities early in the SDLC. It’s also important to configure the 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, while those aren’t the only vulnerabilities to worry about, it’s also helpful to be able to test more broadly in all cases.

2. Identify Code Exposure in Third-Party Code

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 the 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.

A solution that mitigates code exposure from third-party components by scanning builds to identify all open-source components is used. Look for solutions that provide 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 software security solutions are integrated into build processes, then reviewed and acted upon with every build.

3. 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 teams 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.

At the End of the Day

There is no silver bullet when it comes to creating a secure application, security by design should be the primary thought process to ensure that both the positive and negative uses cases can be safely executed by a well-written program. A tool is only as good as the configuration and the recommendations by the tool are only as good as the engineer implementing those recommendations.

I am however glad that such a tool exists so I can encourage my team members to increase their knowledge and provide a safe and secure application for our customers. Thank you for taking the time to read my experience at Netrust, I also want to add that at Netrust we provide consultancy to not just deploy but effectively use secure development tools, do reach out to us at sales@netrust.net if you are keen on a quick chat with my consultants.

Follow us on LinkedIn for the latest happenings/updates.

 

*Content credits: Checkmarx