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

Burger King Site Hacked

Twitter hacked by Iranian Army

espn site hacked with unicorns

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

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.

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…”

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

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

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”)

Application Security Responsibility

Definition : Broad…

Code Quality ~ (“reliability, efficiency, scalability, security, maintainability, readability”)

In abstract..

“Secure” your transports(TCP\UDP)

“Secure” your application layers(Http\s)

“Secure” your data(Resources, configurations, physical, virtual, sockets, files, users etc)

“Secure” your code.

“Secure” your interactions.

Lock Everything…

Defense In Depth(SD, client, Server)

Layers of Defense

Typical User Process Space

Stack Smashing..

Stack Code Escalation

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.

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

Example 1: Code Quality

Open Source Apache Project:

Designing HW Independent Code

Replace with Simple Simulator proxy

Process Improvements1. 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”

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.

Review and Check-In Sign-Off Passed

Review and Check-In Sign-Off Failed

Static Analysis: Identifying issues

Sample coverage report with Issues

Sample coverage report

Git - CI process flow Diagram

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

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

Code CoverageTypically code coverage has two components viz.,

Collection Component:

Jacoco for Java

gcov for c\c++

SonarSource c++ Component

BullsEye

Rational Purify Plus

Analsysis Component:

Sonar Qube

lcov with gcov output

BullsEye

Rational Purify Plus

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.

Design and Code ReviewsTool Used : Code Collaborator, review board, gerritt, github

Reviews Vs WalkThroughs.

What is important is enforcing the Reviews!!

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.

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.

Code quality, in effect software security

-- Thank you

-- Q && A:If(we know)

{

“We will answer”;

}

else

{

“Will find out”;

}

Santhosh Kumar Edukulla