Kiuwan logo

5 Steps to Integrate SAST into Your DevSecOps Process

Code analysis platform example graphic

Source code vulnerabilities are one of the central openings that allow threat actors to carry out their cyberattacks. From code injection to denial of service (DOS) attacks, hackers can exploit these vulnerabilities to access users’ information. They may even move laterally to infiltrate networks and execute a costly data breach. 

Static Application Security Testing (SAST) allows developers to identify errors in their source code while writing their script, enabling them to build higher-quality products that will endure the ever-changing threat landscape. Integrating SAST tools into teams’ development environment can involve several steps, but it ultimately streamlines the software development lifecycle (SDLC) and helps developers write cleaner, more robust code. The result is greater code security, more efficient development processes, and an end product less likely to be exploited by a threat. 

Let’s understand the five stages of SAST integration. We’ll also examine some essential standards teams can refer to and show how Kiuwan’s SAST code security tools can improve DevSecOps processes. 

The 5 Stages of SAST Integration

Before diving into the details, it helps to have a high-level overview of the SAST integration process. In addition to the original onboarding phase, SAST tools typically function at the pre-commit, commit, build, and test checks. Therefore, a general SAST integration outline: 

  1. Application onboarding: The source code is uploaded and scanned. The results are then audited and triaged for remediation. 
  2. Ruleset configuration (SAST01): The SAST tool evaluates inputted source code in real-time so developers can adjust. 
  3. Client’s top 10 issues (SAST02): Rulesets are configured to check for client-specific requirements. 
  4. Industry-standard issues (SAST03): Rulesets for leading security standards, such as the OWASP Top 10, are added. 
  5. Comprehensive rulesets (SAST04): Any additional rulesets are added.

There is no one-size-fits-all approach to integrating a SAST tool into an integrated development environment (IDE), as the exact parameters and errors that teams will scan for will vary with each application. However, by employing it at the stages above, teams can maximize their SAST tool’s capabilities and optimize their DevSecOps processes. 

1. Application Onboarding

It’s the first step involved in integrating SAST into the DevSecOps process. This consists of uploading, scanning, rule configuring, and auditing the source code. It should begin with a clean cache to ensure that old or temporary files are removed. The security analyst and development team should collaborate as they conduct the initial scan. The steps required for a successful onboarding include

  • Gathering all source code, libraries, and artifacts from all necessary repositories;
  • Configuring the initial criteria that will determine when an error has occurred
  • Running the initial scan;
  • Labeling each result (“Urgent”, “False Positive”, etc.); 
  • Triaging the results and resolving the most pressing ones first; and
  • Automating the SAST tool so that it continually runs as teams write their code.

Once the team has remediated all vulnerabilities identified by the first scan, the SAST tool will upload the results to the enterprise server and automatically merge any new scans with the previous report. This prevents developers from duplicating their work and allows them to focus their vulnerability remediation efforts only on the latest bugs introduced. This way, the application onboarding stage provides developers with a baseline scan and is a foundation for future work. 

2. Ruleset Configuration (SAST01)

As with many tools, the initial SAST setup can be the most intensive part of the process. The following steps are, therefore, considerably more straightforward than the onboarding phase — proving that SAST tools are well worth the original investment.

The second stage of the process, the ruleset configuration phase, involves introducing the SAST plugin to the team’s IDE. Here, the tool scans the source code as developers write it, making recommendations and alerting them to errors. Some of the rules that may be configured for the SAST tool to check for are

  • SQL injections,
  • Hard-code credentials,
  • Configuration reviews,
  • Cross-site scripting (stored and reflected), and
  • Resource leaking.

As teams configure their rulesets, they should know their tools’ limitations. SAST solutions have many advanced capabilities, but they lack the contextual understanding of what the application will be used for or what would constitute an error in real life. Therefore, they may generate multiple false positives, slowing developers’ coding. To avoid this, teams must be careful to configure their rulesets to keep the number of false positives to a minimum.

3. Client’s Top 10 Issues (SAST02)

Because it would prove too tedious to resolve every single issue as it arises, developers often write new code and check it into a version control repository. This is where the next stage of SAST integration occurs. 

In this phase, the SAST tool scans the code according to the same rulesets prescribed in the ruleset configuration, except that developers can implement additional criteria, such as the client’s top 10 issues.  Here are some examples of rulesets at this stage:

  • Resource leaks: same as SAST01
  • Hard-coded credentials: same as SAST01
  • SQL injection: same as SAST01
  • Cross-site scripting (stored and reflected): same as SAST01
  • Session management
  • Configuration review

Because of the overlap between this and the previous stage, a scan at this phase only takes up to five minutes — proof of the tool’s efficiency. 

4. Industry Standard Top 10 Issues (SAST03)

Some sectors must follow industry-specific guidelines as they develop their code. The most prevalent example is applications or products that use web services and follow the Open Worldwide Application Security Project (OWASP). Other examples include rulesets using REST services or other custom frameworks. 

The exact rules configured at this phase may depend upon which standard or framework developers use, but some of the most common SAST rules are:

  • Malicious file execution,
  • Insecure direct object reference,
  • Information leakage and error handling,
  • Command injection,
  • Weak encryption,
  • Denial of service,
  • Path manipulation, and
  • Insecure cryptographic storage.

The scans associated with this phase take slightly longer than before, often taking only 10–15 minutes to complete. Developers conduct other development and testing activities parallel to this scan, further elevating teams’ efficiency.

5. Comprehensive Ruleset (SAST04)

In this final phase, developers add any other rulesets needed to clean up their code. The result combines the SAST03 and SAST04 rulesets, creating a comprehensive set of criteria to test their script thoroughly. 

The goal of the SAST scan at this phase is to catch any errors before the code goes into production so that it’s the broadest. The list is not exhaustive, but here are some of the most common rules to check for:

  • XML injection
  • XPath injection
  • XML external entity
  • Open redirect
  • DOM XSS
  • Cookie injection
  • Expression language (EL) injection
  • Header injection
  • LDAP injection

Because the ruleset at this phase covers all bases, the final scan can take a bit longer. It usually takes 60–90 minutes but can take up to a few hours, depending on the code size. However, using the “divide and conquer” approach and spreading the rule checking across multiple phases of the DevSecOps pipeline can minimize the time needed for the final scan, keeping teams as efficient as possible.

Strengthen Code Security with SAST Integration

Code vulnerabilities can be a leading risk for a cyberattack. SAST tools help detect errors in proprietary source code so that teams can catch them as they arise — reducing their technical debt. Teams should refer to industry-appropriate standards and create custom rulesets to ensure that their SAST tools identify errors and keep false positives to a minimum. The process is an investment, but the payoff is a more efficient SDLC, higher-quality code, and a better, safer product.

Kiuwan offers Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools for proprietary and open-source code. Our code security solutions are supported by the leading programming languages and IDEs, making them compatible with nearly any tech stack. Request a demo today to see how our products can strengthen your code security.

Get Your FREE Demo of Kiuwan Application Security Today!

Identify and remediate vulnerabilities with fast and efficient scanning and reporting. We are compliant with all security standards and offer tailored packages to mitigate your cyber risk within the SDLC.

Related Posts

© 2024 Kiuwan. All Rights Reserved.