We’ve made it to the two-year anniversary of the SolarWinds cybersecurity breach. Not the anniversary of its public disclosure, but during Fall 2019 attackers first gained access to the SolarWinds systems. There’s a lot to learn from the breach. The biggest takeaway? Supply chain vulnerabilities are not to be taken lightly.

The breach highlights the significance of a thorough and robust review of security vulnerabilities in the source code of software products – namely hidden backdoors. Analyzing the attack, the threat actors were able to inject malicious code and successfully masquerade the payload, which should have been detected during a secure code review or audit activity focused on finding anomalies or a malicious piece of code.

While many software suppliers today do some form of secure code review activity on their software, there are major variations in the depth and breadth of reviews performed across companies that can drastically impact results. In this blog, I’ll dive into the secure code review process and explain the necessary components needed to identify the risk your source code may pose to your organization if it is not reviewed thoroughly.

What is a Secure Code Review? 

For a detailed and digestible breakdown of secure code review, read OWASP’s Code Review Guide. The authors reiterate that “secure code review is the single-most effective technique for identifying security bugs early in the system development lifecycle.” Let’s start with the basics:

As I define it, secure code review is a process used to verify if the source code being developed contains security flaws and that it has the necessary security controls to prevent an adversary – external or internal – from exploiting vulnerabilities in software.

In other words, the purpose of a secure code review is not only to find security vulnerabilities but also to evaluate if the source code is robust enough to evade security attacks. In addition, it can also verify that developers are following your secure development policies and procedures.

While penetration testing can help you look at your application security holistically, supplementing your testing strategy with a secure code review allows for more comprehensive coverage. According to the OWASP Code Review Guide, “a general rule of thumb is that a penetration test should not discover any additional application vulnerabilities relating to the developed code after the application has undergone a proper security code review.” 

When Should I Implement Secure Code Review or Static Analysis? 

Depending on the criticality of the application and AppSec program maturity, security teams may implement secure code review at various touchpoints in the SDLC or bake it into an Agile development process. 

Just as penetration testing adds more value to your security program when it is implemented continuously, secure code review – when done incrementally and across the SDLC – can dramatically improve your secure software development lifecycle. Below, I outline five key timeframes where secure code review or static application security testing (SAST) should be implemented:

  1. During development:
    Integrating security scanning directly into the developer’s integrated development environment (IDE) is a great way to avoid introducing security vulnerabilities in your code as the software is being written. It provides real-time feedback on secure coding guidelines and is also a great tool to help your teams get in the habit of secure development. Finding and fixing vulnerabilities during development ensures they do not get propagated further down the road. According to National Institute of Standards and Technologies (NIST), the cost of fixing a security defect once it’s made it to production can be up to 60 times more expensive than during the development cycle.
  1. Pre-commit checks (pull/merge requests):
    When merging code from multiple developers into a single branch, it is highly likely that security vulnerabilities will be introduced. While peer code reviews on pull requests generally focus on functional bugs, it is recommended to also do a quick check on security issues. This will help eliminate critical and high severity issues early in the chain. Today, all popular code repositories with code collaboration features provide integration with SAST tools. However, automated tools tend to be too noisy and should be carefully configured with limited rulesets at this stage to not significantly impact developer workflow.
  1. Post-commit (during build/testing phase):
    As source code gets ready to be part of final release of a product, a thorough secure code review is critical to ensure the product is free of security bugs. SAST tools with a broader ruleset can be integrated into continuous integration pipelines to report on existing security vulnerabilities, which can be reported into bug trackers or team backlogs.

    However, breaking the build every time a security bug is reported may not be viable, since tools are prone to false positives. One can improve static analyzers by refining rulesets using regular feedback from reported issues.
  1. Post deployment:
    While integrating static analysis tools in the DevSecOps pipeline may seem straight forward, the speed at which new code is expected to release makes it harder to find and fix all security bugs in every sprint or release.

    Running a SAST scan periodically from production code repositories and having scheduled secure code reviews implemented into your annual calendar will help give your security posture a boost. Also, these help meet the requirements of governing bodies and regulations such as PCI DSS and HIPAA.

    To eliminate noise and reduce the workload on developers, these scans should be triaged by your product security experts, or “champions,” who can closely work with the developers to resolve vulnerabilities. However, not all organizations are adequately staffed with security analysts that have secure code review skills making partnering with a secure code review vendor a viable option. 
  1. Suspicion of malicious intent:
    This is a more reactive strategy for secure code review. When you’re suspicious of malicious activity in your organization, or have detected a potential breach, do an on-demand code review scan to validate your suspicions and identify the breach at its core.

    Remember that code review activities should be aligned with your organizations goals and provide value. For example, in case of malicious threat vectors, review should be focused on identifying points of interest (POI) in code that can combine to produce malicious constructs. Analyze the interaction between various POIs, looking for mutation, obfuscation, and inversion of control used to conceal malicious activity.

The Secure Code Review Process

There are many variables that can impact the secure code review process. As mentioned at the beginning of this article, the depth and breadth of a secure code review can vary greatly. To get the most out of your testing, here are four areas that can make the biggest difference:

  1. Define the Scope
    The scope of each secure code review will vary based upon a multitude of factors, including the threat factors involved, the coding languages, number of lines of code, and the criticality of the application. Is it a “crown jewel” application? If so, it will be important to increase the frequency of your code review cycles and put emphasis on the remediation of vulnerabilities.
  1. Custom Checklists
    Predefined, custom checklists based on the threat model of your product are essential for secure code review success. Generic checklists aren’t very helpful, considering application security is not one-size-fits-all. Custom checklists for each software application can be extremely time-consuming. To help, use frameworks such as the OWASP Application Security Verification Standard as a starting point. Lastly, and perhaps most importantly, ensure your checklists are consistently maintained and updated.
  1. Automated Scanning
    Automated vulnerability scanning enables manual testers to spend more time finding business-critical vulnerabilities in the code. All automated scanning tools are not created equally – some are better than others and some meet unique needs. Are your tools meeting your requirements? Are you being strategic with your automated scanning? Audit and recognize whether there are existing gaps in your tooling and have a plan to evolve and enhance your technologies. Look for these three qualities in your automated scanning tools: the ability to be customized, integrate into the CI/CD pipeline, and reduce noise/false positives.
  1. Manual Testing
    To find vulnerabilities that tools miss, human context is necessary. Manual secure code review is especially important for high-risk, sensitive applications – the one with greater business risk. Humans can apply the needed business logic to write custom scripts and approach a secure code review from the perspective of a real adversary. Additionally, with automation, comes false positives. Having a human triage, the vulnerabilities found in your code is a huge benefit – consuming a raw, data-heavy report is not enough. 

How to Choose Your Secure Code Review Team

To outsource or not to outsource. There are benefits to building a secure code review team within your organization, but it does require a lot of investment and time to evolve your tools and train new resources. Do you have the capacity to maintain the automated scanners, increase the frequency of your secure code review, and update your checklists? If not, here are four reasons to consider working with a secure code review provider:

  1. Better coverage (more vulnerability findings) because they are focused on one activity vs. internal teams who are typically pulled into many different security activities.
  2. Work with your vendor to find the best balance between automated scanning and manual testing.
  3. Contextual remediation recommendations. Plus, the development of code libraries that can be leveraged for remediation.
  4. Dynamic reporting via NetSPI’s Penetration Testing as a Service (PTaaS). NetSPI delivers all secure code review results through its PTaaS delivery platform. The platform enables:
    1. Enhanced, real-time reporting
    2. Accelerated remediation
    3. Reduced administrative time
    4. Continuous testing
    5. Faster vulnerability scanning with Scan Monster™, our proprietary continuous scanning technology

Final words

As discussed above, to prevent your organization from falling victim to next major supply chain attack implementing regular secure code reviews is an essential touchpoint. While continuous static analysis checks provide valuable integration in development environment, adoption should be incremental as per your program goals – and without significantly impacting developer workflow. Collecting feedback from SAST tools, customizing rulesets, and adopting manual code review and verification process are all useful contributors to enhance your application security posture.

Start your Secure Code Review Journey with NetSPI