Static Application Security Testing (SAST) introduces challenges with existing Software Development Lifecycle Configurations. Strategies at different points of the SDLC improve deployment time, while still improving the quality and security of the deliverable. This session will discuss the different strategies that can be implemented for SAST within SDLC—strategies catering to developers versus security analysts versus release engineers. The strategies consider the challenges each team may encounter, allowing them to incorporate security testing without jeopardizing deadlines or existing process.
2. Presenters
Kevin Fealey
• Lead, Automation and Integration Services @ Aspect
Security
• 5+ years of experience with SAST and DAST tools
• @secfealz
William Frontiero
• IBMer
• Senior Worldwide Escalation Engineer AppScan Source
• 10 Years SDLC experience, including 2 years of SAST
tools
1
3. Takeaways
• What is SAST?
• Common SAST Usage
• SAST Automation
• Provide faster feedback to developers
• Simplify the security analysis workflow
• Incorporating Open Source Tools
• Looking at the AppScan SDK
• Jenkins Plugin
• Next Steps
• Improved AppScan Source API
• Application Server Importer
2
5. Why do we need tools?
44
More apps to
review
Flat AppSec
budgets
A need for
scalable, efficient
solutions
Vulnerabilities
are being
introduced
This is starting to change, but slowly…
6. 5
When to Fix Security Issues
Fixing an issue in development is 30x cheaper than when it’s
in production!
5
$139.00
$1,390.00
$2,780.00
$4,170.00
$-
$500.00
$1,000.00
$1,500.00
$2,000.00
$2,500.00
$3,000.00
$3,500.00
$4,000.00
$4,500.00
Coding Testing Beta Release
Cost to Fix a Vulnerability
Depends on When it is Found
8. 7
SAST’s Benefits
• Static Application Security Testing (SAST)
• Analyzes applications at rest (source code/compiled
code)
• Automates code review… to a point
• Data/control flow analysis and advanced grep
• Ex. IBM Security AppScan Source
7
Strengths
• Can traverse millions of lines of code in hours
• If it can find one instance of an issue, it can find all
instances in the application
Weaknesses
• Application must build
• Lots of false-positives out-of-the-box
11. Receive a source
code archive
Extract code and
import into
AppScan Source
Scan, resolve
compilation issues
(often many)
Triage scan
results
Export or write
report
Deliver Report
Begin again with a
new application
10
Security Analyst Workflow
Security Professionals using AppScan Source for Security:
10
Total time: 2-3 weeks / application
• Applications are scanned once per year or less
• Minimal carry-over for subsequent scans
12. Click scan
Wait for scan to
complete
Triage scan
results
Resolve
vulnerabilities
Check code into
central
repository
11
Developer Workflow
Any developer using AppScan Source for Development:
11
Total Time: ½ - 1 day
• Developers cannot develop while scanning (can take hours)
• Developers are not security experts
• Scan workflow interrupts agile workflows
14. Automation Components
• Continuous Integration (CI) Server (ex. Jenkins)
• AppScan Source (or other SAST tool)
• AppScan Enterprise (or other Dashboard/Reporting tool)
• Source code repositories (SVN, ClearCase, git, etc.)
13
Example Architecture
15. 14
Security Analyst Workflow
Security Professionals using AppScan Source for Security:
First Scan:
14
Sync Code
Import into
AppScan
Source
Scan, resolve
compilation
issues
Configure scan
frequency in CI
server
Total time: 2-3 days
Subsequent Scans:
Log into CI
server
Click Scan
Download
assessment
file and triage
scan results
Total time: 1 day
17. 16
Centralized Bundles
16
Use of a centralized environment drastically reduces the time
required for subsequent assessments.
Security Analyst
Only new findings
are triaged
(and bundled)
Scan Server
Scan Results
Downloaded
Triaged Scan Results
(Bundled)
Security Analyst
Subsequent Scans
Triaged
Results
Uploaded
Scan Results
Downloaded
New Vulnerabilities
Already Triaged
Initial Scan
18. 17
Developer Workflow
• Any Developer (IDE Plugin optional)
Total time: Minutes 17
Check code
into central
repository
Receive high-
confidence
findings via e-
mail
Resolve
vulnerabilities
20. 19
Potential Scans Per Year
19
26
65
0
10
20
30
40
50
60
70
Current Workflow Automation Workflow
Applications
Workflow
Per Security Analyst
Security Analyst
(best case scenario)
21. Enterprise Rollout of AppScan Source: Strategy
20
Application Portfolio
Less CriticalMore Critical
Coverage/Assurance
Scan
Scan
Scan
FullScan/Review
Remediation
Guidance
IncreaseCoverage
ReduceRisk
• More time to review critical applications
• More time to find and fix complex issues
22. Improving Security Visibility
Business and
Executive Management
Software
Development Security
and Audit
Visibility
• Developers receive everything they need to resolve issues.
• Managers receive everything they need to make smart business
decisions.
• IT Security receives everything they need to understand
compliance risks.
23. Build/Release Engineer & Dev Ops
• Automate (CI/scripts) simple security checks before each CD release
• No security expertise required
– If certain vulnerability types are found, do not push release/notify stakeholders
– Only sees actionable results
• Iterative triage to accumulate vulnerable/trusted patterns and APIs
• Incremental vulnerability reporting
• Only investigate new vulnerabilities to reduce remediation time and focus
on what is new and relevant
22
Security
30. 29
Open Source Jenkins Plugin
• Available TODAY!
• As a work in progress
• Developed by Aspect Security and IBM
• Hosted on GitHub
• https://github.com/aspectsecurity/sensor-integration-framework
29
32. 31
What’s Next?
• The AppScan Source SDK continues to improve
• Assessment Parsing for External tooling
• Viewing findings in Web Portal
• Diffing at the SDK level
• Improve Jenkins Plugin
• Support Additional Dashboard/Reporting Engines:
– Jenkins
– SonarQube
• AppScan Source App Server Importer Plugin Architecture
• Point and Shoot Discovery of EARs and WARs
• Discover Applications via Import
• Successive scans can be run via automation
31
34. More Questions
William Frontiero: wfronti@us.ibm.com
Kevin Fealey: Kevin.Fealey@AspectSecurity.com
@secfealz
https://github.com/aspectsecurity/sensor-integration-framework
33
36. 35
Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products in connection with this
publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to
interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not limited
to, the implied warranties of merchantability and fitness for a particular purpose.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any
IBM patents, copyrights, trademarks or other intellectual property right.
• IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on
Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower,
PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®,
PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS,
StoredIQ, Tivoli®, Trusteer®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z®
Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions
worldwide. Other product and service names might be trademarks of IBM or other companies. A current list
of IBM trademarks is available on the Web at "Copyright and trademark information" at:
www.ibm.com/legal/copytrade.shtml.
37. Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.
Notas del editor
Source: US Dept. of Commerce, National Institute of Standards & Technology (NIST). "Planning Report 02-3: The Economic Impacts of Inadequate Infrastructure for Software Testing." Technology Program Office, Strategic Planning & Economic Analysis Group. May, 2002. www.nist.gov/director/prog-ofc/report02-3.pdf
Assumes 10 days per app currently and 4 days per app in a
(52*5)/<#days/application> (estimated)