How to Fix a Veracode Static Analysis Flaw in 3rd-Party Software

Veracode Static Analysis aims to find new security flaws in your applications, what is typically called first-party code. However, up-to 90 percent of an application may be made up of software written outside of the organization, typically called third-party software. Software Composition Analysis is responsible for securing third-party components.

Veracode Static Analysis focuses on first-party code by using several heuristics to determine what is and is not third party, for example by determining if something is part of a supported framework .

However, Veracode Static Analysis will occasionally mistake third-party code for first-party code and analyze it for flaws..

Often times during a consultation the question will come up, do I need to fix this?
 

Do I Need to Fix Flaws Found in Third-Party Software?

While Veracode Static Analysis performs the analysis on the application, Veracode does not mandate what should and should not be fixed. This is impossible as Veracode does not control your organizations budget.
 

You should review documentation from your security team, if provided, or contact them if you have any questions on what is or is not required.

Having said this, the Veracode Application Security Consultants recommend at the very least reviewing the flaws found and determining how they impact your application, business, and users.

This is because risk from usage is typically still on the first party (unless there are specific and very rare contracts). It does not typically matter who 'owns the source code', any security risk from using that code still affects the business.

As an analogy, consider that you are not developing an application but building a house (the excellent book Code Complete suggests this as a useful analogy). When you build a house, you will not typically build every component from scratch. Instead of sawing down trees to get wooden beams you will buy wooden beams from a supplier. If, however, these wooden beams are rotten or are unable to bear the weight put on them by your construction, then it will still be your house that collapses on you.

Recommended Steps for Resolution

Veracode Application Security Consultants recommend following the following steps in order to remediate security flaws found by Veracode Static Analysis in third-party software.

If, after reading this, you have any remaining questions or concerns we recommend scheduling a consultation call to discuss.

You can check out this knowledge article (https://community.veracode.com/s/article/How-to-schedule-a-consultation-call) on how to schedule a consultation call with us.

1. Remediate or fix the flaw

If:

• you have access to the source code (the component is Open Source or distributed in source form) and
• you have license to modify and
• the flaw can be fixed through a code change

Then you may be able to simply fix the component and hopefully supply the change 'upstream' to the vendor or Open Source repository.
 

The major benefit is that not only is your application more secure, but other applications using the same component from your organization and/or all over the world are more secure!
 

2. Analyze the flaw and identify any possible mitigating factors

If you do not have access to the source code or license to modify, you may need to work with the vendor to gain access to the source code or supply details of the flaw to the vendor and ask them to review. Typically vendors will be very interested and willing to cooperate in ensuring that their code is secure as long as you approach them with a curious, instead of judgmental, intent and tone.

If the flaw cannot be fixed through a code change, you may need to see if there are mitigating factors that remove the risk and can be documented using a mitigation proposal. Often the component from the vendor may have mitigating controls (such as input validation).
 

3. Add mitigating factors (input validation)

Sometimes you can add a mitigating control that removes the risk in the first-party code that uses the third-party code and can be documented using a mitigation proposal.

In some cases, you can use the data path feature to help determine where the first-party code connects to the third-party code. More information on reviewing static findings including usage of data paths can be found in the help documentation for Reviewing Static Flaws.

Consider the following third-party repository class with SQL injection:

// INSECURE CODE

public class ThirdPartyRepository

{

   public Person findById(String id) {

      return queryOne("SELECT * FROM person WHERE id = " + id);

   }

This can still be used safely by ensuring input validation is always done on the id:

public class PersonController {
    ThirdPartyRepository repository;
    @GetMapping("/person")
    public String person(@RequestParam String id) {
        if (!id.matches("\\d{1,10}")) {
            throw new SecurityException("Invalid ID provided to /person", id);
        }
        repository.findById(id);

In this example the input is tested to ensure it can only be numeric and can thus be safely used in an SQL query.
Please note that Veracode Static Analysis does not analyze regexes and will not be able to automatically mark this as fixed.
You will need to a propose a mitigation like:

Technique: M1 - Establish and maintain control over all of your inputs.
Specifics: ThirdPartyRepository.findById is vulnerable to SQL injection through the id parameter. We have added the following input validation:

         if (!id.matches("\\d{1,10}")) {
            throw new SecurityException("Invalid ID provided to /person", id); 
        } 
Remaining Risk: This dangerous API is still part of our code base, the vendor has been made aware but has not responded, we have added documentation in our project documentation and codebase that this is a dangerous API that requires validation.
Verification: The PersonControllerTest verifies that non-numeric ids are rejected, this was also verified manually.

Frequently risky 3rd-party functionality can also be disabled through not using certain parts or through configuration.

4. Replace the component with a more secure alternative

If security risk cannot be remediated/fixed or mitigated, you may have to consider removing the component and replacing it with a more secure alternative. Depending on how much the component is used in the application, this may be a costly operation.

To prevent running into this when the cost is greatest (at the end of a project) we recommend scanning early and often.