Code Quality - Security

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

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(TCPUDP)
“Secure” your application layers(Https)
“Secure” your data(Resources, configurations, physical, virtual,
sockets, files, users etc)
“Secure” your code.
“Secure” your interactions.

Defense In Depth(SD, client,
Server)

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

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

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

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 Reviews
Tool 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

Code Quality - Security

Recommended

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to Code Quality - Security (20)

Recently uploaded (20)

Code Quality - Security