SDLC Automation
Make me a sandwich
SDLC
Clone
Design
Develop
Commit
Local
Repo
Push
Remote
Repo
(GitHub)
Sync
Deploy
Secure
Test
Finished
App
Build
Build
Server
(Jenkins)
Premise
• We need to prevent recurring vulnerabilities
• Humans cannot keep pace with CI or XP
• Snippet code reviews are error prone
• SAST & DAST need to be integrated in the SDLC
• We need to find vulnerabilities early in the SDLC
Cost of finding vulnerabilities
• Costs increase as a function of distance from IDE
• Costs increase as a function of time
• Security code reviews are usually done last
• This is usually “crunch time”
Git
• A version control system, with client/server architecture
• Allows for multiple developers to work on code in parallel
• After code is ready, it is committed to a local repository
• Code is then sent to a remote repository via a push
• Developers can create new branches
• Branches can get merged to master later
• Git provides facilities for resolving conflicts
• Master is usually what hits production
Git pre/post commit hooks
• Two common integration points are pre and post commit hooks
• Allows for triggering events based on different stages of development
• Hooks allow for the execution of various tools/scripts
• Each type of hook has plusses and minuses
Local hooks
• Local hooks are stored in the local repo’s .git/hooks directory.
• Not copied into the remote repo when pushing
• Can create them in other repos and use symlinks to centrally manage and
share them
• Local hooks can be overwritten by devs, so you can’t guarantee their execution
• A non-zero result aborts the commit
• Post-commit hooks are non-blocking and basically used for notifications.
Server-side hooks
• Stored on the remote server.
• Pre-receive hooks can block pushes prior to allowing changes on the server
• Updates are basically the same, but run once per branch
• Updates allow for failing just one of the pushed branches
• Post-receive is best used for notifications or triggering CI systems.
Webhooks
Since you can’t run normal server-side hooks on Github.com (think RCE), GitHub
offers Webhooks, which can be used to call a URL upon a certain action taking
place.
You can then run tests on the servers which receive the requests from the
webhooks, or pass them along to others in your environment.
One strategy for handling test failures is to have the tests close the loop by taking
actions on GitHub.com via a service account. This could be rolling back commits,
or other remediation actions.
Build servers
• Allow for creating final applications
• Uses centrally controlled libraries
• Avoids the “works on my box” problem
Jenkins
A type of build server software, forked from another,
named Hudson
Can integrate with version control systems to
automatically build on pushes to source control.
Allows for testing of fully built applications using proper
libraries.
Jenkins Plugins
• Numerous plugins allowing for a wide range of build tasks
• Can be conditional
• Can be time-based/recurring
• Can be local scripts or remote API calls
Support commercial vendor tools (e.g. Veracode)
Configuring Github Auth
• Create read-only account
• Several authentication options
• SSH is probably the easiest
Configuring polling
• Configure repo to monitor
• Can be configured to automatically
build on changes
Building
• Language dependent
• Compiling
• Compiling tests
• Running tests
• Packaging
• Static Analysis (Quality)
• Reporting
Build Steps actions
• Build tree of conditionals
• Numerous criteria available
• Can build in file sentinels
• Only run on good builds
Build Steps actions
• Can run virtually any shell command
• Wrappers are advised/necessary
• Local tools could cause issues
Build Steps actions
• Call web APIs to start tests
• Remote API could house scripts
• Pass/fail on HTTP response code
• Pass/fail on response body
• Ability to set timeout
Considerations
• You may not want to install tools directly on the build server
• Don’t let errors in your tools/
configuration break builds
• Monitor your tool status
• Wrapper scripts are probably best
Objectives
• Leverage existing tools
• Prevent recurring bugs
• Remove low-hanging fruit
• Find bugs as early as possible
• Don’t break the bank
• Accurate results
• Improve and track code coverage
SDLC Automation Integration points
Clone
Design
Develop
Commit
Local
Repo
Push
Remote
Repo
(GitHub)
Sync
Deploy
Secure
Test
Finished
App
Build
Build
Server
(Jenkins)
Integration point issues
• Local hooks can be ignored or disabled
• Webhooks require additional infrastructure
• Build process is later than ideal
• The QA staff may not be ideal security testers
Strategies
• Run something at every step vs. in select steps
• Limit when and how frequently tests are run
• Start with just reporting results to security
• Leverage open-source and home-grown tools
• Accept existing non-critical debt
• Initially focus on stemming the tide
Some options
• Burp Suite - Carbonator
• ZAP - Existing Jenkins Plugin
• NMap - NSE Scripts
• (No)SQLMap
• Custom scripts
• Tool orchestration frameworks
Building your own tools
• Feasibility depends on talent/budget/timeframe
• Doesn’t have to be “from scratch”
• Should be time savers in the medium term
• Framework doesn’t necessarily have to be written by the security team
• Allows flexibility to focus on your most common/critical bugs
Building your own SAST Tool
Static Application Security Testing (Static Code Analysis)
Two general approaches
• RegEx
•
Prone to false positives/negatives;
•
Can get messy real quick
•
Passable for simple checks
• Parser/Lexer- Essentially, robust RegEx you didn’t write and tokenization
Build or borrow?
Build a parser generator
• Probably a waste of time
Build a parser
• ANTLR, PLY
•
Parser generator
•
Defines grammar
•
Grammar used to create trees
•
Trees walked by parsers
Borrow a parser, if you can find one
• Example: PLYJ
What’s a grammar?
// PARSER
program : ((assignment|expression) ';')+;
assignment : ID '=' expression;
expression : expression ('*'|'/') expression # multOrDiv
| expression ('+'|'-') expression # addOrSubtract;
// LEXER
ID
: ('a'..'z'|'A'..'Z')+;
Improving automation
Remediate
False
Positives/
Negatives
Automation
tool
Scan
Block Commits
Review
Results
Fail Builds
File Tickets
Ongoing research,
Vulnerability
reports
Contact
★ Patrick Albert - Director of Operations, Tinder
○ https://www.linkedin.com/in/patrickalbert
○ @xphreckx
★ Tony Trummer - Director of Security, Tinder
○ https://www.linkedin.com/in/tonytrummer
○ @SecBro1