Static Code Analysis Vishwas S P Overview Static

Static Code Analysis Vishwas S. P.

Overview • Static Code Analysis (also known as Source Code Analysis) is usually performed as part of a Code Review (also known as white-box testing) and is carried out at the Implementation phase of a Security Development Lifecycle (SDL). Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within 'static' (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis.

Language support for Open Source code Languages Tools Fortify Coverity Kritika Sonar. Qube Checkmarx Snyk Guardrails Go. Lang C C++ Java. Script Python Groovy

Analysis Based on the previous table, the analysis are captured for the tools which supports Go. Lang. Rank Tools Github Integration Support for Docker Cost Open Source SCM Support Saa S Rules confi g Remarks 4 Fortify Don’t see the proper documentation Couldn’t find it Cost involved No Yes Data Sheet Yes It supports on demand scanning, but it is expensive. 2 Sonar. Qube Easy github plugin Scanner Info Server Info Yes Docker Free for open source project, except for C, C++ Pricing Yes • Get Started • Jenkins Configurati on • Sonar Scanner Yes It supports Go. Lang, but C/C++ scanning works only on Enterprise version. 3 Snyk Integration not supported for Go. Lang (Details) No for Go. Lang Free for open source project Pricing No Yes Documentatio n Yes Snyk supports testing and monitoring Go projects that have their dependencies managed by dep or govendor. Go support is currently supported via the Snyk CLI and Git Integrations Snyk now has a Docker based CLI that supports Go Lang with go modules https: //hub. docker. com/r/snyk-cli 1 Guardrails Need to see how this could work for Edge. X Foundry. Free for open source project Pricing TBD No Yes Seems like limited support for Go. Lang Yes Paid clients have additional functionality for CLI and PR support

Setup and Configuration • Scanner: https: //docs. sonarqube. org/display/SCAN/Analyzing+with+Sonar. Qube +Scanner • Server configuration using standalone approach https: //docs. sonarqube. org/latest/setup/get-started-2 -minutes/ • Server configuration using Docker approach https: //hub. docker. com/_/sonarqube/

Sonar. Qube – Issue edits • • • Confirm - By confirming an issue, you're basically saying "Yep, that's a problem. " Doing so moves it out of "Open" status to "Confirmed". False Positive - Looking at the issue in context, you realize that for whatever reason, this issue isn't actually a problem. So you mark it False Positive and move on. Requires Administer Issues permission on the project. Won't Fix - Looking at the issue in context, you realize that while it's a valid issue it's not one that actually needs fixing. In other words, it represents accepted technical debt. So you mark it Won't Fix and move on. Requires Administer Issues permission on the project. Severity change - This is the middle ground between the first two options. Yes, it's a problem, but it's not as bad a problem as the rule's default severity makes it out to be. Or perhaps it's actually far worse. Either way, you adjust the severity of the issue to bring it in line with what you feel it deserves. Requires Administer Issues permission on the project. Resolve - If you think you've fixed an open issue, you can Resolve it. If you're right, the next analysis will move it to closed status. If you're wrong, its status will go to re-opened. Additionally, Security Hotspots allow the following: Detect - Confirms a Security Hotspot as a true issue and manually opens a Vulnerability. Requires Administer Security Hotspots on the project. Clear - Marks a Security Hotspot or manually opened Vulnerability as being without issue and shouldn't be fixed. Requires Administer Security Hotspots on the project. Request Review - Request that a Security Auditor review changes made to remediate a manually opened Vulnerability. Reject - After review , reject the remediation for a manually opened Vulnerability and return it to an open issue. Requires Administer Security Hotspots on the project.

Sonar. Qube – Handling false positive Select the false positive issues and click on Bulk Change

Sonar. Qube – Handling false positive Resolve as false positive, provide the reason and apply https: //docs. sonarqube. org/latest/user-guide/issues/

Sonar. Qube – Issue Owner • Once issues have been through technical review, it's time to decide who's going to deal them. By default they're assigned to the last committer on the issue line (at the time the issue is raised), but you can certainly reassign them to yourself or someone else. The assignee will receive email notification of the assignment if he signed up for notifications, and the assignment will show up everywhere the issue is displayed, including in the My Issues list in the My Account space.

Sonar. Qube – Rules https: //docs. sonarqube. org/latest/user-guide/rules/ There are four types of rules: • • Code Smell (Maintainability domain) Bug (Reliability domain) Vulnerability (Security domain) Security Hotspot (Security domain) For Code Smells and Bugs, zero false-positives are expected. At least this is the target so that developers don't have to wonder if a fix is required. For Vulnerabilities, the target is to have more than 80% of the issues to be true-positives. Security Hotspot rules are purposefully designed to draw attention to code is security-sensitive. It is expected that more than 80% of the issues will be quickly resolved as "Won't Fix" after review by a Security Auditor.

Sonar. Qube – Rules https: //docs. sonarqube. org/latest/user-guide/rules/ • Under the Rules menu we can filter the rules based on many criteria as shown in this picture. Filter can also be performed based on Tag, Repository, Severity, Status etc • To see the details of a rule, either click on it, or use the right arrow key. Along with basic rule data, you'll also be able to see which, if any, profiles it's active in and how many open issues have been raised with it.

Sonar. Qube – Rules https: //docs. sonarqube. org/latest/user-guide/rules/ • There are templates of rules available for different languages • We can create our own custom rules as well • Don’t see the support for custom rules for Go. Lang https: //docs. sonarqube. org/display/DEV/Adding+Coding+Rules • I see only two Vulnerability rules for Go. Lang • • Credentials should not be hard-coded IP addresses should not be hardcoded

Demo

Backup

Background • There are various techniques to analyze static source code for potential vulnerabilities that maybe combined into one solution. These techniques are often derived from compiler technologies. • Data Flow Analysis • Data flow analysis is used to collect run-time (dynamic) information about data in software while it is in a static state • Control Flow Graph (CFG) • Taint Analysis attempts to identify variables that have been 'tainted' with user controllable input and traces them to possible vulnerable functions also known as a 'sink'. • Lexical Analysis converts source code syntax into ‘tokens’ of information in an attempt to abstract the source code and make it easier to manipulate