Code Quality - Security
- 1. Code Quality - Security Session Topics: • Understand few terms, terminologies, known Issues and process problems • Software security development cycle, leverage tools and build effective processes. • Example projects(OpenSource and Commercial) Santhosh Kumar Edukulla
- 2. Burger King Site Hacked
- 3. Twitter hacked by Iranian Army
- 4. espn site hacked with unicorns
- 5. Few Numbers, Known Issues • More than 70% of attacks “targeted” are application related, of which web vulnerabilities are getting prevalent. • espn, sony, ebay, yahoo, twitter, facebook, dropbox, microsoft …even google is not spared
- 6. Few Examples Few Code Samples: • All the samples if we see are functionally wrong, even otherwise lead them to security issues. • All these issues can be caught during code reviews, static analysis, or other code check process.
- 7. Core pillars of information security (CIA) • Confidentiality – only allow access to data for which the user is permitted • Integrity – ensure data is not tampered or altered by unauthorized users • Availability – ensure systems and data are available to authorized users when they need it In typical SDLC, “Security starts from requirements phase itself and it never ends…”
- 8. Principles of Information Security • Minimize attack surface area • Establish secure defaults • Principle of least privilege • Principle of defense in depth • Fail securely • Don’t trust services • Avoid security by obscurity • Fix security issues correctly • Keep security simple
- 9. OWASP Top Web Vulnerabilities OWASP urges all companies to be aware of these concerns within their organization and start the process of ensuring that their web applications do not contain these flaws. • A1 Injection • A2 Broken Authentication and Session Management • A3 Cross Site Scripting (XSS) • A4 Insecure Direct Object References • A5 Security Misconfiguration • A6 Sensitive Data Exposure • A7 Missing Function Level Access Control • A8 Cross Site Request Forgery (CSRF) • A9 Using Components with Known Vulnerabilities • A10 Invalidated Redirects and Forwards
- 10. Code Quality : Functional (Vs) Non Functional Definition of Quality: Broad…but should not be fixed only to functional quality of a software product. Code Quality ~ (“reliability, efficiency, scalability, security, maintainability, readability”)
- 11. Application Security Responsibility Definition : Broad… Code Quality ~ (“reliability, efficiency, scalability, security, maintainability, readability”)
- 12. In abstract.. “Secure” your transports(TCPUDP) “Secure” your application layers(Https) “Secure” your data(Resources, configurations, physical, virtual, sockets, files, users etc) “Secure” your code. “Secure” your interactions.
- 14. Defense In Depth(SD, client, Server)
- 16. Typical User Process Space
- 17. Stack Smashing..
- 19. Code Quality : Goals and Objectives • One of the key goal for every dev team should be to pass on less number of bugs to QA. • One of the key goal for every dev team should be to have less number of design bugs in production and identified more during reviews. • The number of issues identified during design and code reviews quantified with metrics against the total bugs for a release, how many of them were caught in Dev (Vs) QA etc. • The sign off criteria for a build or feature should be from design sign off, code reviews sign off, zero static analysis bugs, zero profiling bugs detected by agreed upon tool etc. • In fact, each sprint definition of done should and must be enforced by quality parameters.
- 20. Few Gates • Effective SCM, commit process, defining Check-In criteria • Reviews and Walkthroughs( Design and Code ) • Effective code analysis (SAST DAST ), profiling techniques. • Effective Quality CI Pipeline
- 21. Example 1: Code Quality Open Source Apache Project:
- 22. Designing HW Independent Code Replace with Simple Simulator proxy
- 23. Process Improvements 1. CI Cycle Improvements. 2. Categorized the Integration tests to “Self-Service” (Vs) “Hardware” dependent 3. “Two” LGTM(+1s ) for every commit request. No “-1” 4. 100% Unit test coverage. 5. “0” slow static analysis and “0” full Coverity bugs. 6. New Integration Tests should be added, if it’s a new feature commit. 7. Integration test coverage should not regress the previous ones. 8. All Self-Service tests should pass 100%. 9. No new OWASP, sec bugs found with Sonar/Coverity rules engine. 10. Style and license check should pass 100% 11. New feature design document should have at least “2 LGTMs”
- 24. Tools Used • Jenkins • Git(SCM) • Gerritt • ReviewBoard(Code Review) • Coverity, findbugs, PMD for static analysis • Jira(For bug tracking) • Jacoco, SonarQube for Coverage Analysis. • Nose, coverage for integration tests.
- 25. Review and Check-In Sign-Off Passed
- 26. Review and Check-In Sign-Off Failed
- 27. Static Analysis: Identifying issues
- 28. Sample coverage report with Issues
- 30. Git - CI process flow Diagram
- 31. Code Coverage What is is not for: It does not signify quality “completeness” criteria. A 100% coverage information does not signify high quality and no bugs. Tools can report 100% coverage, but still it does not mean code is covered fully. What it is for: Finding “Covered” and “Uncovered Areas”. Priority Vs Non Priority Areas Priority Tests Vs Non Priority Tests
- 32. Coverage Types • Statement Coverage • Decision Coverage • Condition Coverage • Multiple Condition Coverage • Condition/Decision Coverage • Modified Condition/Decision Coverage • Path Coverage • Function Coverage • Call Coverage • Linear Code Sequence and Jump (LCSAJ) Coverage • Data Flow Coverage • Object Code Branch Coverage • Loop Coverage • Race Coverage • Relational Operator Coverage • Weak Mutation Coverage
- 33. Code Coverage Typically code coverage has two components viz., Collection Component: − Jacoco for Java − gcov for cc++ − SonarSource c++ Component − BullsEye − Rational Purify Plus Analsysis Component: − Sonar Qube − lcov with gcov output − BullsEye − Rational Purify Plus
- 34. Check-in Criteria. We had an integration of coverity with our svn server. Every check-in is first analyzed for coverity run automatically and any checkers marked and finding high severity bugs was not allowed to be checked in with a failed commit. We had a valgrind running at scheduled intervals on build and emailing the list of issues and creating bugs automatically. Any issue reported on new checkins are reverted automatically. Zero Coverity and Code Collaborator defects for check-in was adopted, otherwise commit wont be allowed and it is automated. Failing Sanity run through AutoBVT on staging build wont push the commits to production. Production push happens automatically only when staging build gets passed. Peer Review Sign off for every checkin and in case of no signoff, commit wont get committed.
- 35. Design and Code Reviews Tool Used : Code Collaborator, review board, gerritt, github Reviews Vs WalkThroughs. What is important is enforcing the Reviews!!
- 36. Profiling and Dynamic Analysis Tools Used: Rational purify plus, coverity, valgrind, gprof, vtune, oprofile etc. Valgrind: It is an effective memory analysis and debugging tool, not an effective for memory analysis with static allocation, anything with dynamic memory allocation, it is very effective. It is limited in support on various platforms and not extensive like Rational Purify Plus, free and lot of community and user support available. Rational Purify Plus : Supports lots of platforms, wealth of documentation, good support, does static analysis, dynamic analysis, and does provide coverage information as well, but little pricey :) Gprof with krprof : Easily usable with gcc tools on the fly with limited tool set. A common complaint about these is their excessive rate of false alarms and that the warnings they issue do not correlate very well with real defects.
- 37. To Summarize.. 1. Don’t trust your inputs, don’t trust your code, any inputs from any sources. Validate all Input Sources EX: • Browser input, headers, request parameters. • Cookies • Property files • External processes • Data feeds • Service responses • Flat files • Command line parameters • Environment variables 2. Follow effective commit and build CI process. 3. Effective Reviews, tools, Coverage, sign-off criteria, early fixes 4. Follow Secure Coding Guidelines, many of them are available at OWASP site. 5. Follow a threat model for your projects. 6. Get to an effective assurance level agreed upon.
- 38. Code quality, in effect software security -- Thank you -- Q && A: If(we know) { “We will answer”; } else { “Will find out”; } Santhosh Kumar Edukulla