Overview Static Code Analysis also known as Source Code Analysis is usually performed as part of a Code Review also known as whitebox 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 ID: 1047571
Download Presentation The PPT/PDF document "Static Code Analysis Vishwas S.P." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. Static Code AnalysisVishwas S.P.
2. OverviewStatic 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.
3. Language support for Open Source code Languages Tools GoLangCC++JavaScriptPythonGroovyFortifyCoverityKritikaSonarQubeCheckmarxSnykGuardrails
4. AnalysisRankToolsGithub IntegrationSupport for DockerCostOpen SourceSCM SupportSaaSRules configRemarks4FortifyDon’t see the proper documentationCouldn’t find itCost involvedNoYesData SheetYesYesIt supports on demand scanning, but it is expensive.2SonarQubeEasy github pluginScanner Info Server InfoYesDockerFree for open source project, except for C, C++PricingYesYes Get StartedJenkins ConfigurationSonar ScannerYes YesIt supports GoLang, but C/C++ scanning works only on Enterprise version.3SnykIntegration not supported for GoLang (Details)No for GoLangFree for open source projectPricingNoYesDocumentationYesYesSnyk 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 IntegrationsSeems like limited support for GoLang1GuardrailsNeed to see how this could work for EdgeX Foundry. Free for open source projectPricing TBDNoYesYesYesPaid clients have additional functionality for CLI and PR supportBased on the previous table, the analysis are captured for the tools which supports GoLang.Snyk now has a Docker based CLI that supports Go Lang with go moduleshttps://hub.docker.com/r/snyk/snyk-cli
5. Setup and ConfigurationScanner:https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+ScannerServer configuration using standalone approachhttps://docs.sonarqube.org/latest/setup/get-started-2-minutes/Server configuration using Docker approachhttps://hub.docker.com/_/sonarqube/
6. SonarQube – Issue editsConfirm - 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.
7. SonarQube – Handling false positiveSelect the false positive issues and click on Bulk Change
8. SonarQube – Handling false positiveResolve as false positive, provide the reason and applyhttps://docs.sonarqube.org/latest/user-guide/issues/
9. SonarQube – Issue OwnerOnce 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.
10. SonarQube – RulesThere 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.https://docs.sonarqube.org/latest/user-guide/rules/
11. SonarQube – Ruleshttps://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 etcTo 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.
12. SonarQube – Ruleshttps://docs.sonarqube.org/latest/user-guide/rules/There are templates of rules available for different languages We can create our own custom rules as wellDon’t see the support for custom rules for GoLanghttps://docs.sonarqube.org/display/DEV/Adding+Coding+RulesI see only two Vulnerability rules for GoLangCredentials should not be hard-codedIP addresses should not be hardcoded
13. Demo
14. Backup
15. BackgroundThere 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 AnalysisData flow analysis is used to collect run-time (dynamic) information about data in software while it is in a static stateControl Flow Graph (CFG)Taint AnalysisTaint 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 AnalysisLexical Analysis converts source code syntax into ‘tokens’ of information in an attempt to abstract the source code and make it easier to manipulate