Download as PDF, PPTX
Uploaded byEmerasoft, solutions to collaborate
SCA del Software Open Source: come interpretarlo per evitare problemi di sicurezza?
The document discusses the importance of accurate data for automating software security processes, particularly in the context of open-source software. It emphasizes that relying on public vulnerability databases can lead to excessive false positives and negatives, potentially hindering innovation and developer trust. Recommendations include using proprietary intelligence, curating data, and providing developers with contextual remediation guidance to enhance security practices without creating friction.
More Related Content
Similar to SCA del Software Open Source: come interpretarlo per evitare problemi di sicurezza?
![[Europe merge world tour] Coverity Development Testing](https://cdn.slidesharecdn.com/ss_thumbnails/europe-mergeworldtourcoveritydevelopmenttesting-130718033654-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
More from Emerasoft, solutions to collaborate
SCA del Software Open Source: come interpretarlo per evitare problemi di sicurezza?
- 1. SCA del SoftwareOpen Source: come interpretarlo per evitare problemi di sicurezza? Fabrizio Corsaro, Customer Success Engineering - Sonatype Marcella Arrabito, Marketing Manager - Emerasoft
- 4.
- 6. What are theright things to do?
- 7. When you climbthe mountain every day, it’s easier.
- 8.
- 9. Do Acceleration through Automation. Automationis only possible if the data is precise and accurate. This enables faster time to market. Don’t False positives and false negatives inhibit automation. Which causes slow innovation as developers spend time chasing and remediating incorrect data.
- 10. What’s the evidenceto require automation and data accuracy? The volume and scale of which Open Source is being consumed
- 11. OSS download volumesare a proxy for build automation
- 13. Transitive dependencies (Mavencentral Aug 2013) Complex interedependencies
- 14. Do Examine OSS componentsvia binary libraries. It’s precise and accurate. Don’t Examine and match OSS components via file names and package manifests. It’s prone to error. Filenames can (and have been known to) be renamed to match whitelists.
- 15. Do Trust professionally curateddata & proprietary research. It’s a vastly superior and specialised source of vulnerability intelligence. Don’t Depend on public NVD data or commodity research vendors. They are inadequate sources of vulnerability information available to the public.
- 16.
- 17. Real-Time Results withInaccurate Data • Large bank scanning results • Sonatype vs Major Competitor • False Positive/False Negative • Why? Sonatype 100+ security researchers vs Public NVD data
- 18. Do Match accurate scansagainst proprietary intelligence. It’s proven to generate true positives and true negatives. Don’t Match Filenames or manifests against public NVD and commodity data. It is guaranteed to generate excessive false ‘positives’ and false ‘negatives’.
- 19. The Anatomy ofa False Positive
- 20. Name based matchingincorrectly associates risk Issue Sonatype Cause Sonatype Vendor 1 Vendor 2 Vendor 3 OWASP DepCheck CVE-2012-xx xx poi-scratchpa d True Negative False Positive False Positive False Positive False Positive CVE-2014-xx xx poi-ooxml True Negative False Positive True Negative False Positive False Positive CVE-2014-xx xx poi-ooxml True Negative False Positive True Negative False Positive False Positive CVE-2014-xx xx poi-scratchpa d True Negative False Positive False Positive False Positive False Positive CVE-2017-xx xx poi-examples True Negative False Positive True Negative False Positive False Positive CVE-2017-xx xx poi-ooxml True Negative False Positive False Positive False Positive False Positive Vendor Component Name: Apache POI 3.7 Vendor Scanned Component: org.apache.poi:poi-3.7.jar CPE from NVD: cpe:2.3:a:apache:poi Savings: Research time to prove false positives. Rework time to upgrade when not required
- 21. The True Costof False-Positives and False-Negatives
- 22. Automated decisions requirehigh quality data • False positives and incorrect issue identification incur research costs or an upgrade costs • False negatives leave you at risk Component Sonatype Vendor 1 Vendor 2 OWASP DepCheck Commons Collections 3.2 & 3.2.1 1 True Negative 2 True Positives 1 False Positive 1 False Negative 1 Incorrect ID 1 True Negative 2 Incorrect IDs 1 True Negative 1 Incorrect ID Active MQ 12 True Negatives 2 True Positives 2 True Negatives 1 True Positive 10 False Positives 1 False Negative 2 True Positives 12 False Positives Apache MyFaces 2.0.8 1 True Negative 1 True Positive 1 True Negative 1 True Positive 1 False Positive 1 False Negative 1 True Positive 1 True Negative Apache POI 2.5.1-final-200408 6 True Negative 6 True Negative 6 False Positives 6 False Positives ICU for Java 3.4.1 7 True Negatives 7 True Negatives 7 False Positives jQuery 1.11.2 1 True Positive 1 False Negative 1 False Positive 1 True Positive Spring Transaction 3.0.5 10 True Negatives 10 True Negatives 10 False Positives 10 False Positives mysql-connector-java-5.1.40 98 True Negatives 98 False Positives Rich Faces 4.0 Final 3 True Positives 3 False Negatives 1 False Negative 2 Incorrect IDs
- 23. Name Based MatchingCreates Rework and Risk. False positives are the silent killer
- 24. 6000 Components analyzed(~1531 artifact discrepancies) • 4500 Non Issues • 1034 True Positives (1 in 6 is a valid finding) • 5330 False Positives when CPE was part of the component name • 2969 False Negatives when CPE was not in the component name
- 25. The maths: • 10%vulnerable
- 26.
- 27. • Curation ofData - Automated matching of component & CVE • Human checking & resolution of anomalies in the matching • Proprietary ISSUES (if no public CVE) from range of data sources Component Identification Cryptographic Hash, Structural Similarity, Derived Coordinate, and Filename CPE Common Platform Enumeration Matches which CVEs a component is vulnerable to (Mapping table) Done with curation (automation & human checking) CVE Common Vulnerability & Exposures (listed in NVD & Sonatype proprietary
- 28. How to Enable Developers ToBuild Secure Software
- 29. Do Provide developers componentintelligence inside their favourite tools. It’s key to DevSecOps. Don’t Force developers to use tools designed for security. It’s counter to DevSecOps.
- 31. Do Provide remediation guidance. Withinthe development environment. Don’t Assume developers can determine remediation. It’s time consuming for developers to investigate all remediation options and processes.
- 32.
- 33. Do Automatically enforce OpenSource policy and control risk across every phase of the Software Development Lifecycle. It empowers developers and accelerates innovation. Don’t Scan and scold developers. It creates friction and decreases trust and innovation.
- 34. Give Developers aHead Start
- 35. Do Use a Firewallaround your private repositories. OSS Firewall allows you to block components before they are even downloaded by developers. Don’t Wait until the end of the project and produce a report or shelf ware and tell developers that they’re baby is ugly. It creates friction and decreases motivation impacting speed to market and innovation.
- 36. Do Provide partial matching,demonstrate similar and exact matches. Gives flexibility to the developers. Don’t Rely purely on the name of a library. Mask the true investigation needed to match the component to the CVE.
- 37. How to TackleLegacy Applications
- 38. Do Enable a granularflexible contextual policy. It allows the customisation of policies to meet specific compliance goals or mandates and/or organisation wide policies. Don’t Enforce a blanket policy for all applications. It doesn’t consider criticality of application or specific compliance mandates.
- 39. Do Grandfathering. Grandfathering allows prioritisationof remediation of legacy applications. Don’t Limited prioritisation. Limited ability to prioritise applications based on your risk factors.
- 40.
- 41. When you climbthe mountain every day, it’s easier.
- 42.
- 43.