Shift-Left with Secure Coding for Web Applications

Over the past year or so, I’ve been contemplating how application development teams can embrace security as part of their development workflows without having the security focus slow down software development.  As developers aim to secure code from the start, education, visibility, and guidance are paramount to help them adapt quickly and not slow them down.

Static application security testing (SAST) seems like a prime area where developers’ efficiency can be improved while they learn secure coding practices.  SAST can be used early in the software development lifecycle to check for potential source code issues defined by a community-developed list of common weakness enumerations (CWE’s).  When a SAST scan identifies a CWE in source code, it is helpful for developers to understand the specific risk, coding best practices to avoid it, and fixes to remove the vulnerable code. Developers should also be able to take advantage of AI as much as possible in their coding, but with assurances about the security of code suggestions - AI should be aware of secure coding patterns and potential vulnerabilities and is providing secure fix suggestions that do not introduce additional risks.

I’ve been evaluating two common SAST offerings, GitLab SAST and Snyk Secure Code, and each vendor’s respective AI offerings and built-in training content, with a focus on the developer’s perspective: 

As a software developer writing code via my IDE for a web application, I want to be alerted quickly to potential weaknesses that need to be addressed in my code and helped to fix them so that I can push secure code to the repository and not introduce any new potential vulnerabilities.

From that perspective, my SAST scan criteria are:

1. Speed at which I receive feedback about potential SAST vulnerabilities

2. Accuracy of scan results

3. Information provided to explain why the vulnerability exists, what the risks are, and how to fix

4. AI remediation options to apply the fix quickly

For my evaluation purposes, I used Visual Studio Code as my IDE.  The good news - both GitLab and Snyk provide Visual Studio Code extensions that are easy to install and configure and make development tasks easy with their tools.  But there are some huge differences between how each works.

	Snyk	GitLab
Scan context	Scan whatever is open in your VS Code Workspace	All scans run in a CI pipeline, typically executed on push to remote repository
Scan results	Results with full details are visible via the extension	Results with full details are visible via the extension
Identifying vulnerable code	Snyk highlights vulnerable lines of code in the IDE to help you understand where fixes need to be applied	The vulnerability details page in the IDE provides the file path and line number, but clicking that link brings you to the web ui where the specific lines of code where vulnerabilities exist are highlighted
Viewing additional learning resources	Additional learning resources are linked to the vulnerability details displayed within the IDE	Additional learning resources are only available on the vulnerability details page in the web UI
AI code remediation	Available within the IDE so that changes can be applied and tested locally before being pushed to the repository	Only available via the web UI for vulnerabilities in the default branch

Note that in the comparison, I am excluding the GitLab web IDE from the classification of IDE as I believe that most developers do not use the GitLab web IDE. GitLab provides IDE integrations with Visual Studio, Visual Studio Code, and JetBrains.  Snyk provides integrations for these as well as with Eclipse.

In my evaluation, the scan context is the biggest advantage of Snyk’s behavior in the IDE.  If I’m coding, I don’t want to have to push my changes to the remote first and then find a potential vulnerability.  I want to validate my code and then fix it before pushing it.  And I don’t want to necessarily worry about whether the entire CI/CD pipeline will pass in order to validate that my code changes don’t contain any new vulnerabilities.  I certainly don’t want to wait for an entire pipeline to complete, as is suggested by the prescriptive auto devops pipeline that GitLab provides especially if the pipeline has many stages and jobs such as DAST running against a review app (side note - please optimize pipelines for speed of feedback on feature branches!).  I should get my SAST results much faster than that so that I can understand where there are weaknesses in my code, learn how to fix them, and continue to code, before pushing code to my feature branch for full validation via a CI pipeline.  

You can view a demo of the Snyk Source Code capabilities via the IDE.

The GitLab pipeline results presented in the IDE have one big advantage that might make it worth the extra wait time -  the vulnerabilities presented in the IDE are specific to the code changes in the feature branch associated with the MR that I am pushing to.  That is significant if there are existing SAST findings in the main branch that have not been resolved. In this case, I do not want to see them reported to me as findings in my code.  I only want to see the new issues that I have introduced with my code changes, and that is what the GitLab vulnerability list shows me in the IDE.  This was more challenging to see from the Snyk tool.  Snyk does have a closed beta feature of PR checks for source code changes that seems promising here.  When I enabled PR checks for open source dependencies with the GitLab integration, I noticed that my GitLab pipelines that ran had an extra “external job” that shows the PR check and links to a Snyk page that has details with the check results.  

I would guess that something similar occurs for the source code issues found but I have not been able to evaluate it.  And it’s unclear to me at this point if the specific vulnerabilities will be easily findable via the IDE without having to walk through every code diff.

The DeepCode AI capability that suggests validated fixes for vulnerabilities right from the IDE also seems like a huge timesaver from a developer perspective.  Snyk provides one or more fix options, allows me to navigate through all options easily to compare them, and apply them directly to the file in my editor.  And Snyk validates that any fix does not inadvertently introduce a new vulnerability.

GitLab has an AI capability to fix SAST vulnerabilities as part of its Duo Enterprise add-on, but it’s currently only available in the UI, and only from the vulnerability report, which reports on vulnerabilities in the default branch.  There are no AI capabilities yet to help developers working on their feature branch remediate SAST vulnerabilities. 

You can view a demo of GitLab Duo Enterprise vulnerability explanation and vulnerability resolution capabilities.

Vulnerability resolution in the merge request is planned and being tracked in epic 14862.  While I could not find a specific issue for adding the AI vulnerability fix to the IDE, GitLab does have extensive AI capabilities available within the IDE, including Code Suggestions, so I would expect to see this available once vulnerability resolution in the merge request is GA.  Overall, I think one of the biggest advantages of GitLab is in having AI throughout the development lifecycle to improve developer efficiency, and that might make any limitations in IDE offerings for SAST remediation seem insignificant compared to the other advantages it brings.

Both GitLab and Snyk provide helpful security training linked to vulnerability details.  While Snyk has built its own training library, GitLab uses integrations with popular security training sites: Secure Code Warrior, Kontra, and SecureFlag.  In my review, the content seems similarly helpful across the offerings, with concrete examples and sandbox environments for developers to use for learning.  The one advantage of Snyk is that it provides links to appropriate training articles from a vulnerability details page, whether viewed from the UI or IDE while GitLab only provides the links to the integrated training from within the UI.

At this point, I’m not quite ready to tackle the topic of accuracy of results.  I will say that the findings were very different between the GitLab Semgrep and Advanced SAST scans, where Semgrep found 51 vulnerabilities using the default GitLab ruleset and Advanced SAST found 35.  Snyk identified 176 issues, 80 of which can be fixed using the DeepCode AI.  I’ll have to take a closer look at the findings to evaluate the discrepancies.

GitLab and Snyk take different approaches when it comes to source code scanning and aiding developers in applying fixes to make their code more secure.  Overall, it seems that Snyk might have an advantage in terms of developer efficiency by providing robust IDE capabilities.  However, GitLab’s continued focus on the entire development lifecycle with AI built in might negate any advantages Snyk’s IDE capabilities deliver.

What’s your favorite SAST tool?  Are there others I should evaluate?  Drop a comment below and let me know.