Presentation from 18 November 2014. Software applications need to be delivered faster and across more platforms than ever. To build high quality software in short order, we’ve seen a dramatic shift from source code to component-based development, with open source and third party components providing the innovation and efficiency that developers need. Unfortunately, our dependence on components is growing faster than our ability to secure them. These shared components are not top-of-mind when considering application risk. Worse yet, components are increasingly the preferred attack surface in today’s applications. The combination of growing component usage, coupled with lack of security, requires us to urgently re-evaluate traditional application security approaches and identify practical next steps for closing this security gap. So what’s the “neglected 90%,” why is it attractive to your adversaries and what can you do about it? Plenty. Here are 7 key points, for starters. http://bit.ly/AHC_USAF

1. 7 Reasons Your Applications are
Attractive to Adversaries
2014 Fall Cyber Security Forum and Expo
Robins Air Force Base
November 18, 2014
1

2. 2 3/19/14
Modern software development
HAS CHANGED
Application security
HASN’T CHANGED
ENOUGH

3. 3 3/19/14
APPLICATIONS
are assembled using
third party “components,”
most of which are open source
In fact,90%
of a typical application
is open source
Source: Sonatype, Inc. analysis based on Application Healthchecks used to determine component risk
in applications.

4. 1
AS OPEN SOURCE USAGE EXPANDS,
SO DOES OUR SHARED RISK

5. Open source usage is
EXPLODING
Yesterday’s source
code is now replaced with
OPEN SOURCE
components
2007 2008 2009 2010 2011 2012 2013
500M 1B 2B 4B 6B 8B 13B
5 Source: Sonatype, Inc. analysis of (Maven) Central Repository component requests.

6. OPEN SOURCE:
PRODUCTIVITY
INNOVATION
SPEED
6

7. 7
OPEN SOURCE:
HACKER TARGETS
NO VISIBILITY
NO CONTROL

8. 2
SMALL EFFORT AND BIG GAINS

9. 9
Now that software is
ASSEMBLED…
Our shared value becomes
our shared attack surface

10. One risky component,
now affects thousands of victims
ONE EASY
TARGET
10

11. 3
YOU USE A SOFTWARE SUPPLY CHAIN.

12. Use of components creates a
SOFTWARE
SUPPLY CHAIN
Component
Selection
DEVELOPMENT BUILD AND DEPLOY PRODUCTION
COMPONENT
SELECTION
12

13. 13
If you’re not using secure
COMPONENTS
you’re not building secure
APPLICATIONS
Component
Selection
DEVELOPMENT BUILD AND DEPLOY PRODUCTION
COMPONENT
SELECTION

14. Component
Selection
DEVELOPMENT BUILD AND DEPLOY PRODUCTION
COMPONENT
SELECTION
Today’s security
ISN’T
WORKING
58m
vulnerable
components
downloaded
!
71%
of apps
have 1+
critical or
severe
vulnerability
!
90%
of
repositories
have 1+
critical
vulnerability
!
14 Source: Sonatype, Inc. analysis based on Repository Healthchecks and Application Healthchecks used
to determine component risk in repositories and applications.

15. Components are like
MOLECULES not atoms.
There are massive dependencies.
Diversity
• 40,000 Projects
• 200M Classes
• 400K Components
Complexity
One component may
rely on 100s of others
Volume
Typical enterprise
consumes 1,000s of
components monthly
Change
Typical component is
updated 4X per year
15 Source: Sonatype, Inc. analysis of (Maven) Central Repository.

16. 4
SECURITY BUDGETS ARE
OUT OF SYNC WITH
RISK AND REALITY

17. #1 ATTACK VECTOR LEADING TO BREACH

18. APPSEC GETS LEAST SPEND, YET MOST BREACHES
spending
18
attack risk
People Security ~$4B
Data Security ~$5B
Host Security ~$10B
Network Security ~$20B
Written code ~10%
Source: Normalized spending numbers from IDC, Gartner, The 451 Group ; since groupings vary
Software
Security
~$0.5B
~90%
Open source
components
Most breached

19. Source: 2014 Sonatype Open Source Development and Application Security Survey
1-IN-10
had or suspected an
open source related breach

20. 5
MANUAL POLICIES JUST DON’T WORK
IN A SECURE DEVELOPMENT LIFECYCLE.

21. CHANGE
Typical component is
updated 4X per year.
21
795,220 OSS COMPONENTS
11 MILLION DEVELOPERS
Source: Components: (Maven) Central Repository; Users: IDC

22. CHANGE
Typical component is
updated 4X per year.
22
Unlike COTS, there is no clear, effective
COMMUNICATION
channel
795,220 OSS COMPONENTS
11 MILLION DEVELOPERS
• Has a risk been identified?
• What type of risk?
• Is a better version available?

23. Manual processes
DON’T WORK
Automation should
ENFORCE
POLICIES
Humans should
manage exceptions
23

24. Bouncy
Castle
CVE Date:
11/10/2007
Java Cryptography API
CVSS v2 Base Score:
10.0 HIGH
Exploitability:
10.0
Since then
11,236 organizations
downloaded it
214,484 times
HttpClient
CVE Date:
11/04/2012
Java HTTP implementation
CVSS v2 Base Score:
5.8 MEDIUM
Exploitability:
8.6
Since then
29,468
organizations
downloaded it
3,749,193 times
Apache
Struts 2
CVE Date:
07/20/2013
Web application framework
CVSS v2 Base Score:
9.3 HIGH
Exploitability:
10
Since then
4,076
organizations
downloaded it
179,050 times
24 Source: Sonatype, Inc. analysis of (Maven) Central downloads and NIST National Vulnerability Database

25. To reduce cost
per defect
!
To achieve
compliance
!
WHY
is this important?
To manage
risk
HttpClient
Struts
Bouncy
Castle
!
25

26. What are you doing to ADDRESS THIS RISK?
26

27. FOSS Review Board
Scans post
development
Golden repository
Approval workflow
27

28. Time for a
FRESH APPROACH?
28
Sonatype Component Lifecycle Management (CLM)
• Precisely identify component
and risks
• Remediate early in development
• Automate policy across the SLC
• Manage risk with
consolidated dashboard
• Continuously monitor apps
for new risks

29. Time for a
FRESH APPROACH?
29
FOR ALL…
COMPONENTS LANGUAGES < > REPOSITORIES DEV TOOLS
Java Java Central
NuGet .NET, C# NuGet Gallery
NPM Javascript NPMJS.org
Gems Ruby, jRuby Jruby.org
Debian APT, OS -
RPM RPM, Yum OS RedHat
PyPi Python Pypi.python.org
Cpan Perl Cpan.org
Hudson
Jenkins
Eclipse
Microsoft
Bamboo
IntelliJ
Oracle
Rundeck
Electric Cloud

30. Time for a
FRESH APPROACH?
CURRENT METHODS SONATYPE CLM
Problem discovery Problem remediation
“Scan and scold”
Source code scanning
Approval-centric workflow
Empower developers
Component analysis
Automated policy across lifecycle
Policy enforcement throughout SLC
Scans after development
30

31. 6
EMPOWER YOUR DEVELOPERS
ON THE FRONT LINE

32. How can we choose the best components
FROM THE START?
Analyze all components
from within your IDE
License, Security and Architecture data for each
component, evaluated against your policy
Shift Left= ZTTR (Zero Time to Remediation)
@451wendy @joshcorman

33. How can we choose the best components
FROM THE START?
Analyze all components
from within your IDE
Single click migration
speeds remediation
33

34. 7
AGILE DEVELOPMENT REQUIRES
AGILE SECURITY.

35. Defense in DEPTH and BREADTH
Continuously monitor
Bill of Materials for
future violations
Stage-appropriate
actions govern the
software lifecycle
35
Apply policies easily to
groups of similar
applications

36. KNOW and TRACK your components
Get a precise, instant
inventory of all open
source components
36
Identify where every
component lives

37. QUICKLY identify threats and manage enterprise RISK
Prioritize fixes by
risk and location
37

38. 38
Never has anything
with this much
IMPACT
been this
EASY …
It’s time to take
ACTION
Why? Because it is
IMPERATIVE
It’s FAST. It’s NOT EXPENSIVE.
There is no possible down-side.
5
MINUTES

39. 39
in
5 MINUTES
accomplish these
3 CRITICAL
STEPS
5
MINUTES

40. 40
Download the
APP
HEALTH
CHECK
STEP 1
5
MINUTES
http://bit.ly/AHC_USAF

41. 41
Discover the security,
license and quality
RISK LEVELS
in each application
STEP 2
5
MINUTES
http://bit.ly/AHC_USAF

42. 42
See
EVERY
COMPONENT
used in your applications
STEP 3
5
MINUTES
http://bit.ly/AHC_USAF

43. 43
See
OZONE
WIDGET
FRAMEWORK
http://bit.ly/AHC_USAF

44. 44
The
DISTRIBUTED
DATA
FRAMEWORK
http://bit.ly/AHC_USAF

45. LET’S GET STARTED
5
MINUTES
http://bit.ly/AHC_USAF