Downloaded 21 times
Uploaded byBlack Duck by Synopsys
Software Security Assurance for DevOps
The document discusses the challenges and strategies related to software security assurance in DevOps, highlighting the growing integration of open source and custom code. It emphasizes the importance of automated security testing and robust governance policies in managing security risks across both types of code. The partnership between HPE Security Fortify and Black Duck aims to enhance visibility and remediation of security vulnerabilities in software development processes.
More Related Content
Similar to Software Security Assurance for DevOps
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
Software Security Assurance for DevOps
- 1. Software Security Assurance forDevOps Mike Pittenger, VP Security Strategy, Black Duck Software Lucas v. Stockhausen, Sr. Product Manager HPE Fortify
- 2. • Challenges impactingapplication security in DevOps • Strategies for overcoming these challenges • 5 Things you can do tomorrow Agenda 2
- 3. Why We Partnered •Organizations today manage application security for both custom and open source code • HPE Security Fortify is a market leader in the application security space for customer code; Black Duck is a market leader in the application security space for open source • Together, we allow customers to manage security risk in custom and open source code, through a single interface 3
- 4. GROWING ATTACK SURFACENEW DEPLOYMENT MODELS Web, Mobile, Cloud, IoT Containers, IT and Small Security Teams • Which apps are people using? • How do I set internal policy requirements for app security? • Is my private / sensitive data exposed by apps? • Who is developing the apps? • How do we prioritize the work for the resources I have? • What do we test and how do we test it? • How do we staff and improve skills and awareness? OPEN SOURCE Increasing Portion of Code Base • What policies are in place for open source use? • How are those policies enforced? • Who is tracking usage for new vulnerabilities Application Security Challenges 4
- 5. • Web applications •Cloud applications and services • IoT Changing Attack Surface 5 “If perimeter control is to remain the paradigm of cybersecurity, then the number of perimeters to defend in the Internet of Things is doubling every 17 months.” Dan Geer In-Q-Tel RSA 2016
- 6. Up to 90% OpenSource TODAY 50% Open Source 2010 20% Open Source 20051998 10% Open Source Open Source is the Foundation of Modern Applications 6
- 7. @FUTUREOFOSS #FUTUREOSS GROWING OPPORTUNITY FOR POLICIES& PROCEDURES 50% Nearly 2016 INSIGHTS 4 @FUTUREOFOSS #FUTUREOSS UNDERSTANDING YOUR OPEN SOURCE CODE Top ways companies review their code for open source Development teams manually keep track of open source use 48% 30% 21% Ask developers about open source content Use third party tools to scan for open source content 2016 INSIGHTS 4 @FUTUREOFOSS #FUTUREOSS HOW ARE COMPANIES HANDLING KNOWN OPEN SOURCE VULNERABILITIES? of companies have no process for identifying, tracking or remediating known open source vulnerabilities Nearly 1/3 2016 INSIGHTS 4 Open source Use has Outpaced Process Maturity Everybody is using open source, but many organizations still do not have adequate processes or tools in place to manage it. 7
- 8. How Well DoManual Processes Work? 8
- 9. OPEN SOURCE CODE DELIVEREDCODE Open Source Enters Your Code in Many Ways… DEVELOPER DOWNLOADS OUTSOURCED DEVELOPMENT THIRD PARTY LIBRARIES CODE REUSE APPROVED COMPONENTS COMMERCIAL APPS …and security, compliance & quality risks can come with it.
- 10. Open Source Vulnerabilitiesare Increasing 10 Reference: Black Duck Software knowledgebase, NVD, VulnDB FREAK!SSL, TLS Vulnerability 0 500 1000 1500 2000 2500 3000 3500 4000 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 NVD Black Duck exclusive
- 11. • Automated testingfinds common vulnerabilities in the code you write • They are good, not perfect • Different tools work better on different classes of bugs • Many types of bugs are undetectable except by trained security researchers Static Analysis Does Not Help With Open Source All possible security vulnerabilities FREAK!
- 12. Four Factors ThatMake Open Source Different 12 Easy access to code Exploits readily availableVulnerabilities are public Used Everywhere
- 13. Who’s Responsible forOpen Source Security? 13 Commercial Code Open Source Code • Dedicated security researchers • Alerting and notification infrastructure • Regular patch updates Dedicated support team with SLA • “Community”-based code analysis • Monitor newsfeeds yourself • No standard patching mechanism Ultimately, you are responsible
- 14. Bad Guys HaveQuotas Too (Non-Targeted Attacks) Rational Choice Theory • Criminals make a conscious, rational choice to commit crimes • Behavior is a personal choice made after weighing costs and benefits of available alternatives • The path of least resistance will be taken
- 15.
- 16. Secure Development Security Testing Continuous Monitoringand Protection Application Security Testing for the New SDLC 16
- 17. HPE Security Fortify andBlack Duck Integration 17
- 18. • HPE SecurityFortify + Black Duck Technology Alliance Partnership • Address pervasive, rapidly-growing Security & Compliance risks with Open Source • Gain visibility on risks across Custom Code and Open Source Code • Integrate governance and remediation as part of Software Security Assurance Black Duck Integration with HPE Security Fortify SSC Risks in Open Source Code (Black Duck Hub) Manage Risks in Open Source as part of HPE Security Fortify SSC Risks in Custom Code with SAST, DAST, & RASP
- 19. Open Source Vulnerabilities– Black Duck 19
- 20. Overview Shows BlackDuck Results Within HPE Security Fortify Open Source vulnerabilities (3rd Party Components) from Black Duck analysis Custom Code vulnerabilities from Fortify SCA analysis
- 21. Detailed View ofBlack Duck Results Within HPE Security Fortify
- 22. Automating Security Testing ina DevOps Environment 22
- 23. Continuous Integration Environment 23 BinaryRepository Management (Artifactory / Nexus) Developers / IDE (Eclipse) Continuous Integration Server (Jenkins / TeamCity / Bamboo) Deployment Environments (Amazon / Docker / VMWare / Openstack) Test Automation Tools (Selenium / JUnit) Quality Management Tools Bug Tracking Tools Source Control Management (Git, CVS / Subversion / Perforce) Build Tools (Maven / Bundler)
- 24. Continuous Integration Environment 24 Developers/ IDE (Eclipse) Continuous Integration Server (Jenkins / TeamCity / Bamboo) Test Automation Tools (Selenium / JUnit) Quality Management Tools Bug Tracking Tools Source Control Management (Git, CVS / Subversion / Perforce) Build Tools (Maven / Bundler) SAST / DAST / IAST SAST / OSS DAST / OSS DAST / OSS SAST / OSS Binary Repository Management (Artifactory / Nexus) Deployment Environments (Amazon / Docker / VMWare / Openstack)
- 25. DELIVERY TEAM VERSION CONTROL BUILD & UNIT TESTS AUTOMATED ACCEPTANCE TESTS USER ACCEPTANCE TESTS RELEASE PIPELINE1 PIPELINE 2 PIPELINE 3 Automation Differs Between Apps 25
- 26. • Speak withyour heads of application security and software development and find out… • What policies exist for managing open source? • Is there a list of components used in all applications? • How are they creating the list? • What controls do they have to ensure nothing gets through? • How are they tracking vulnerabilities for all components over time? • How do they account for the different testing requirements for custom code v. open source? • What is the best security automation strategy for your organization? What Can You Do Tomorrow? 26
- 27.
- 28. tt http://blkduk.io/2vniKhH Or Click Here:http://blkduk.io/2vnikhH
Editor's Notes
- #2 PITTENGER: Welcome! My name is Mike Pittenger and I’m the Vice President of Security Strategy here at Black Duck Software. I’m joined by Lucas von Stockhausen, Sr Product Manager for HPE Security Fortify. Today’s webinar will focus on application security for DevOps and what Black Duck and HPE Security are doing together to help.
- #3 PITTENGER There are 3 Challenges impacting application security in a DevOps world Expanding attack surface Agile + New Delivery Models Rise of open source Strategies for overcoming these challenges Security testing in agile environments Custom and open source Talk about automation 5 Things you can do tomorrow
- #4 Stockhausen HPE Security Fortify and Black Duck recently announced a partnership. The goal of our partnership is to empower organizations with a software security solution, that provides visibility into the security posture of applications across your enterprise, in both custom code and open source libraries. With the partnership and integration, security vulnerabilities identified from Black Duck can now be viewed through Fortify Software Security Center.
- #5 PITTENGER: While automation has addressed the challenge presented by agile development, there are other challenges organizations face when it comes to application security in a changing world. Expanding Attack Surface – * Not only are we seeing a huge increase in the sheer number of web facing applications, but also many more devices in the workspace managing critical data. This can include mobile devices, cloud services, and IoT New Deployment Models * With changing development models and companies moving to an Agile environment, we are also seeing a change in the way applications are being deployed. This leads to new security strategies to address things like the secure use of containers – The greater use Open Source Open source is used virtually everywhere today. This presents some new security challenges from a testing and monitoring perspective. Now, let’s look at each of these in a bit more detail…
- #6 Stockhausen In the connected world of today, when we think of attack surface we're typically discussing web applications. But, it’s not enough to only scan/test your critical web applications. The number of apps continue to increase substantially and companies have come to the realization that applications are a competitive differentiator that sets them apart. As they create complex web apps, mobile apps, and IOT apps, their attack surface expands. There are an ever increasing numbers of web apps which provide customers and adversaries with a way to reach our data and critical assets. But there are other ways in which we’re exposing ourselves to hackers. If we consider IoT apps and device deployments are exploding across commercial, home products, and the automotive industries. Particularly infotainment systems in the connected car. Less visible are business to business and vertical apps, including critical infrastructure. Gartner Research estimates that the installed base of IoT devices, which has almost doubled in the last 2 years, will increase 3–fold in the next 4 years. Dan Geer of In-Q-Tel, the investment arm of the CIA, paints the picture in another way. By looking at the number of CPU cores, device drivers for bluetooth, GPS, video and USB ports, he estimates that the actual attack surface is doubling every 17 months!
- #7 PITTENGER: One of the most challenging aspects of applications and container security is finding open source software vulnerabilities. This is increasingly important. After all, open source software makes up a growing percentage of a companies code base, and containers are commonly built on open source components.
- #8 PITTENGER Open source has been adopted widely, but this has presented new challenges. Primarily, how do organizations manage the code they use. The 2016 Future of Open Source survey shows that Nearly half the companies had no policies for what 3rd party code could be used. Keeping tack of open source is a manual process without controls – about half claim to track manually. As we will see later, this greatly underestimates the amount of open source used Nearly a third of the companies had no process for tracking new vulnerabilities in the code they used. This is compounded, of course, by the fact that most companies have no reliable way of even knowing which open source projects they are using, and the fact that vulnerabilities vary by version
- #9 PITTENGER : Open source is being embraced by organizations, including the federal government. How important is it to understand what your organization is using? Our recent study on open source in commercial applications showed: Go through stats We as security professionals need to recognize that open source and custom code require defense in depth -
- #10 PITTENGER Managing open source can be a challenge, because it can enter into an organizations code base in several ways. An org may have reviewed and approved open source in design reviews, but developers maybe using reused internal code that includes older open source components that have not been approved, or they have pulled unapproved code from web-based repositories, or integrated code from supply chain partners. In all of these scenarios, you are exposing and increasing risk to your organization. The end result is organizations are deployed code that contains open source, often without the knowledge or review of development managers and security teams.
- #11 PITTENGER : There are two very different but equally important application security challenges for organizations. You may recognize the logo’s shown here, but think for a moment about what they have in common They are all vulnerabilities in well known and widely used open source components They were all present in the code for years, in spite of thousands of instances of testing using traditional security tools and pen tests They were all found by security researchers and disclosed responsibly to the public While vulnerabilities like Heartbleed, GHOST, ShellShock, DROWN are well known, they represent a tiny fraction of the vulnerabilities reported in open source. In fact, the National Vulnerability Database has reported over 6,000 new vulnerabilities in open source software since 2014 alone. As you can see in the chart, we see a pretty consistent flow of new vulnerabilities based on the work of security researchers. The spike in the graph shows how the discovery of Heartbleed 2 years ago spurred increased research and scrutiny of open source. And again, while Heartbleed made the evening news, there have been over 70 additional vulnerabilities – just in OpenSSL – since then. The problem this presents is two-fold, visibility to the components you use, and visibility to the vulnerabilities
- #12 PITTENGER Organizations should use static and dynamic analysis to find bugs in the code they write, but… Open source vulnerabilities are too complex and too nuanced to be found by automated tools If the tools were effective at finding vulnerabilities in open source, the vulnerabilities would have been found long ago HeartBleed was present in OpenSSL for 2+ years, despite constant testing using automated tools 50+ vulnerabilities in OpenSSL since Heartbleed have all been found by researchers. Vulnerabilities in open source are almost exclusively found by researchers manually inspecting the code and conducting experiments Of the 4,000 vulnerabilities identified last year, fewer than 10 we Very useful in identifying common security bugs in custom code Typically responsibility of security team Some can integrate into the build Provide a snapshot of security vulnerabilities that each tool can identify Exploitability of an issue can easily change Results require review and scrubbing #1 complaint – too many useless issues Typically used late in the SDLC Often require compiled application and/or test environment re identified by automated tools
- #13 PITTENGER : Open source is not necessarily less secure, or more secure, than commercial software. There are, however, some characteristics of open source that make it particularly attractive to attackers. Open source is widely used by enterprises in commercial applications Therefore, a new vulnerability in a popular project provides a target-rich environment for attackers. Attackers have access to the code for analysis Vulnerabilities in commercial code are exploitable, but attackers don’t have easy access to the source for analysis. That’s not the case in open source, where everyone has access. Like researchers, attackers can also identify new vulnerabilities When new vulnerabilities are disclosed, we publish them to the world NIST maintains the National Vulnerability database as a publicly available reference for vulnerabilities identified in software, and other sources – most notably OSVDB – focus on all identified vulnerabilities in open source. Proof of the vulnerability (in the form of an exploit) is often included When a vulnerability is discovered, the researcher will typically provide proof of the vulnerability in the form of exploit code, making the attackers’ job easier Attackers can use these as well – but if they are confused, there are typically YouTube videos available to provide step-by-step instructions
- #14 PITTENGER: The predominant method for tracking open source in organizations is a manually compiled spreadsheet that is created at the end of the SDLC. While that’s a problem by itself, it’s exacerbated by the lack of visibility into the thousands of vulnerabilities reported in open source each year. Why is this? * Start – open source is no more or less secure than commercial code. However, Characteristics of open source that make it attractive to attackers * support model
- #16 PITTENGER : Now let’s turn it over to Lucas von Stockhausen from HPE Security Fortify to take a look at the some of the available technologies for automating application security testing and implementing the concept of gates / controls.
- #17 Stockhausen: There are a variety of technologies on the market for assessing the security of application. First I’d like to start with Static Analysis. Fortify’s Static Code Analyzer identifies security vulnerabilities in source code during development. It pinpoints the root cause of a vulnerability with line of code detail so that developers can easily ID and quickly remediate issues. It prioritizes results & provides best practices so developers can code securely. SCA also helps organizations identify issues early in the software development lifecycle when they are the easiest & least expensive to fix. Open Source Scanning such as Black Duck also integrates into the build process. This technology assesses your applications to identify known vulnerabilities in the open source components. These vulnerabilities are almost exclusively found by researchers manually inspecting the code and conducting experiments. Dynamic Analysis, Fortify WebInspect is for QA testers & security professionals to help identify and prioritize security vulnerabilities. It simulates real world attacks on your running applications and provides a comprehensive analysis of complex web applications and their services. Runtime is a technology that helps organizations manage and mitigate risk in production applications. Fortify Application Defender is able to actively monitor and protect applications that have known and unknown security vulnerabilities. It also provides visibility into the malicious activity and will identify the root cause. So as orgs are transitioning to an agile environment, processes and greater collaboration across dev, QA and security Ops has to get automated further. The traditional approach is to deploy static and dynamic testing technologies during the build and QA process and although this testing is still important, it is no longer enough. New trends have emerged and we now have a new SDLC – Secure developement is shifting left and empowering developers to find and fix vulnerabilities as they code. This happens entirely within the developers native environment. We do this by continuously testing and providing remediation guidance on the source code as it is being developed. Today, applications have to embed and build-in security testing tools such as Fortify and BlackDuck which can tightly integrate into existing DevOp tools sets
- #19 Stockhausen With this integration, customers that already manage vulnerabilities in Fortify Software Security Center can now incorporate issues that have been identified by BlackDuck. This provides added value, visibility and governance to your entire application security program.
- #20 PITTENGER Black Duck scans are kicked off concurrent with the Fortify scans, typically as part of the build process. The result is an inventory, or bill-of-materials, listing all of the open source identified down to the version level. Once identified, we map information from our knowledgebase on over 1.5 million open source projects about known vulnerabilities, license information, and operational risk from poorly supported projects.
- #21 Stockhausen This is one example demonstrating the usefulness of having Black Duck issues incorporated into Software Security Center. At the issue level, you can see the flexibility that SSC offers. Users can combine filtering with grouping to identify specific types of issues.
- #22 Stockhausen This is one example demonstrating the usefulness of having Black Duck issues incorporated into Software Security Center. At the issue level, you can see the flexibility that SSC offers. Users can combine filtering with grouping to identify specific types of issues.
- #23 This slide will set up the discussion on automation PITTENGER or RIGHT Moving from a waterfall environment to DevOps has changed the way organizations are creating and deploying their applications. The advantages of integrating Development and IT Operation teams, and moving to a continuous and frequent production releases cycle, provides faster time to value, allows companies to react quickly to market needs, and helps to stay ahead of a very competitive environment. A new approach to development also requires a new approach to security testing. As companies transition to a DevOps environment they need to find ways to further automate their application security testing efforts and process. It is even more crucial now to make sure testing processes are built into your SDLC.
- #24 PITTENGER Most continuous integration infrastructures contain a similar collection of components including: IDE’s integrated development environments, version control systems, bug tracking tools, binary repositories, and test automation tools, The most common component is a continuous integration solution such as Jenkins, TeamCity, or Bamboo to orchestrate and schedule all of the critical steps of the build. <ANIM> Application scanning can be implemented in a number of locations within the ecosystem, including automated scanning as part of the continuous integration process which provides visibility into security vulnerabilities within your code.
- #25 PITTENGER Security testing technologies that are integrated with a CI tools provides the most flexibility and reduces friction in the devops environment. For example, using your CI tools to initiate Static and Open Source analysis with each build provides rapid feedback on vulnerabilities in both customer and open source code, giving companies a complete assessment of the risk in an application. As a final check before deployment, a good practice is to run an open source analysis of both the application layer and the Linux stack to identify known vulnerabilities, and if you choose, prevent vulnerable containers from being deployed live.
- #26 PITTENGER To achieve consistency in the build and delivery process, continuous integration solutions can take advantage of pipelines. A pipeline is simply a chain of events that can be scheduled or triggered and are kicked off within your CI system. They can be quite simple and only involve a few tasks or complex and contain many tasks and can include both serial and parallel paths. There is no such thing as a standard pipeline but most incorporate unit tests, acceptance tests, packaging, reporting and deployment phases. It’s not unusual for your CI team to have several software build pipelines constructed to accommodate different types of builds. For example: <ANIM> Pipeline 1 may be invoked each night and only used internally to test the code that was committed to that day. <ANIM> <ANIM> Other pipelines might include more automated testing and deployment and packaging tasks to ready the software for general release and public consumption. <ANIM> You may choose to only include scanning on a subset of your pipelines where you need visibility into security, licensing, and operational risk. You need to be careful not to get in the way of downstream activities such as QA testing. So, if you are adding scanning to your nightly or weekly QA builds, you probably don’t want to fail the builds and slow down the software development testing process. However, prior to releasing software to customers, you may want to leverage the build pass / fail options to monitor configured policy violations and fail the build if they arise. <ANIM> In these situations, the build will be halted and downstream tasks will not be completed. Notifications can be distributed to key personnel to inform them of the failure so it can be addressed. GO TO NEXT SLIDE
- #27 PITTENGER: In summary, we’ve discussed: The application development environment is changing rapidly Security testing in these environments requires further automation to meet the needs of an agile environment OSS is pervasive and integral part of app development OSS has unique security and support challenges Therefore, level of risk warrants action. If you agree this is a priority, the next steps are critical. CISOs we speak with want to find out more about the current situation at their organization. The best person to ask is often the head of application security and software development. What you want to know are the answers to the following questions: What policies exist? Is there a list of components? How are they creating the list? Are they tracking vulnerabilities? How do they ensure nothing gets through? What steps are they taking to automate their processes? These questions will shed light on the current state of how open source is used and managed at your organization and give you a good starting point for further discussions. What would you propose the next steps should be?
- #28 At this point, we’d like to open it up to questions and answer those that have already come into the Chat window…. If you have further questions, please contact us at: