Static code analyzers as a DevSecOps solution

Static code analyzers as a DevSecOps solution April 20, 2019 Holiday Inn Moscow Sokolniki

2 A few words about me • Yuri Minaev • C++ developer in the PVS-Studio company • minaev@viva64.com

4 https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf

6 How to detect vulnerabilities  Code review  Unit-tests and dynamic analysis  Static analysis

8 Code Review • Pros: – Sharing experience – Off the reel fixes • Cons: – Expensive and time-consuming – You get tired of viewing code

9 Static code analysis • Is the same as code review, but automated

10 Static code analysis • Pros: – Less costly – The analyzer doesn’t get tired – The analyzer is aware of error patterns, unknown to programmers • Cons: – False positives – You cannot find high level errors – It’s tricky with multithreading

11 Dynamic analysis • Pros: – Analysis during the performing process – No false positives • Cons: – Sanitizers and profilers are slow – You’ll often need some specific input data – Tests cannot cover all cases

14 Modern analyzers  Integration in IDE  Integration in build systems and CI  Incremental analysis  Mechanisms of noise suppression

15 Integration in CI  Launch as a build step  Reports about found errors

SonarQube • «Control source code quality using the SonarQube platform» http://www.viva64.com/en/b/0452/ 16

17 Static Application Security Testing (SAST)  Automated search of errors in code  Detection of vulnerabilities that occur due to programming errors  More than 60% of vulnerabilities are programming errors © NIST

18 From an error to a vulnerability

19 Two kinds of SAST  Search for known vulnerabilities  Preventing actions against new vulnerabilities

20 Useful terms • CWE – Common Weakness Enumeration • SEI CERT – Software Engineering Institute Coding Standard • CVE - Common Vulnerabilities and Exposures • MISRA - Motor Industry Software Reliability Association

21 • CWE™ is a community-developed list of common software security weaknesses. • Is a list of potential vulnerabilities which can become real. • Website: https://cwe.mitre.org • 806 potential vulnerabilities.

22 • Standard by CERT Coordination Center, CERT/CC • Contains rules for C, C++, Java, Perl • Many matches with CWE • Website: https://wiki.sei.cmu.edu/

23 Example of CWE static void SHA1Final(unsigned char digest[20], SHA1_CTX *context) { u32 i; unsigned char finalcount[8]; .... memset(context->count, 0, 8); memset(finalcount, 0, 8); }

24 Example of CWE static void SHA1Final(unsigned char digest[20], SHA1_CTX *context) { .... memset(finalcount, 0, 8); } CWE-14 V597 The compiler could delete the 'memset' function call, which is used to flush 'finalcount' buffer. The memset_s() function should be used to erase the private data.

25 https://godbolt.org/ CWE-14

26 CWE-14: Compiler Removal of Code to Clear Buffers https://cwe.mitre.org/data/definitions/14.html

27 • CVE - real vulnerabilities, found in applications. • Website: https://cve.mitre.org/ • Total CVE Entries: 114 142

28 static OSStatus SSLVerifySignedServerKeyExchange(....) { .... if ((err = SSLHashSHA1.update( &hashCtx, &signedParams)) != 0) goto fail; goto fail; .... fail: ....; } • V640 The code's operational logic does not correspond with its formatting • V779 Unreachable code detected. It is possible that an error is present CVE-2014-1266

29 typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); } • V642 Saving the 'memcmp' function result inside the 'char' type variable is inappropriate. The significant bits could be lost breaking the program's logic. CVE-2012-2122

30 • Paid coding standard. • Website: https://www.misra.org.uk/ • 143 rules in MISRA-C:2012 • 228 rules in MISRA-C++:2008

31 Examples of MISRA rules • Don’t use octal constants • Don’t use goto • A function has to have only one exit point • Don’t use standard library functions (atof/…/abort/exit/getenv/system/…) • Don’t use dynamic allocations • Each case has to end with break or throw

33 How to use standards incorrectly

34 How to use standards incorrectly

35 What about legacy?  Take an old large project  Run the analysis in your favourite analyzer  And get...

37 How to do it right  Run the analysis one time  Suppress all warnings  Run the analysis on the new code  Gradually fix old code and check edits

40 Conclusions  Security issues cost a lot if they get in a final product  Static code analysis is one of the ways of searching for vulnerabilities  Regular checks allow to eliminate potential vulnerabilities at the earliest stages

41 Q&A  PVS-Studio site: https://www.viva64.com  Contacts: Yuri Minaev minaev@viva64.com

Static code analyzers as a DevSecOps solution

More Related Content

Similar to Static code analyzers as a DevSecOps solution

More from Andrey Karpov

Recently uploaded

Static code analyzers as a DevSecOps solution