- Welcome new team members
- @knqyf263: Embed CPE names into binaries (#76)
- @zmanion and Emily Sarneso: CERT/CC VINCE
- @stevespringett CycloneDX support for vulnerability disclosure and remediation
YouTube recording: https://www.youtube.com/watch?v=7LN5ytkkJ2M
- Welcome new members
- Itay (Aqua Security)
- Teppei (Aqua Security, Trivy)
- Dan (Intel)
- Art (CERT/CC in process of joining OpenSSF)
- Teppei presenting on “Embed CPE names into binaries” (#73)
- Explaining Trivy - open source scanner for artifacts (containers)
- This leverages package managers
- Many official docker images install software using “make”
- There are issues in - scanners can’t detect within self-compiled binaries - it would need a SBoM for binaries
- CPE (Common Platform Enumeration) comes in at this point
- The goal is to associate CPE to Binaries in order to facilitate vulnerability detection
- Sometimes the binary name is different than the production name
- Hash based mappings can be prepared in advance - but this requires a database of all versions
- NOTE: David (in chat): This kind of thing has been proposed before. Embedding CPE names was previously proposed for OWASP Dependency-check by Dale Visser, including a specification and pull request. It wasn’t accepted at that time, for reasons I don’t agree with. It might be a wise time to discuss again & re-introduce this proposal. See: jeremylong/DependencyCheck#298
- Version option based can also be prepared in advance (output needs to be formatted). There is an issue in that “-v” is not standardized
- True, but embedding the data within the binary means that you don’t need to standardize “-v”
- Supporting multiple identifiers seems like a good idea. E.g., be able to embed CPE, puRL, home page URL would be great. I doubt it’d be possible to embed SWID, because that’s a hash, and you can’t embed the hash you still need to calculate, but being able to support other formats would still be an improvement.
- Version option based can also be prepared in advance (output needs to be formatted). There is an issue in that “-v” is not standardized
- First proposal: add new CPE name section, ideally in Makefile, but Dockerfile could suffice
- Proposal Goal: improve accuracy of vulnerability scanners by embed in binaries (useful for host/container scanning), embed in docker labels (useful in container scanning)
- After Presentation:
- @david-a-wheeler Brings up that this was brought up as a pull request to OWASP dependency check (see here)
- @kerberosmansour Brings up this could be useful to locate advisories without scanners by utilizing unique identifiers. Notes: cpe is the most used today
- Discussion bringing up SWIDs are being suggested to be used but they lack versions
- Notes: having both current (cpe) and future (swid) covers current and future
- SBoM data would help everyone be able to accomplish the goal (find vulns without scans)
- Chicken and egg better info helps builds sbom and sbom helps find vulns
- How do we get information (today’s topic) from software that lacks a package manager (i.e. using make) - people have pre-compiled binaries they download (or may build). And the extra data package managers would provide is then not present.
- CPE embedding could be embedded into containers because they are wrapped but this is harder with ruby, perl, python source based languages all choosing different ways to embed the information
- Teppei notes some of these have standardized data today
- We need to decide next steps as a WG
- Art Manion (& Emily Sarneso), CERT/CC (a Federally Funded Research & Development Center (FFRDC) (child of Software Engineering Institute (SEI)) (Emily is lead developer) - help other organizations do the work better of aggregation of vulnerabilities)
- Intend to release as OSS a project that’s basically a bug tracker, but.... They want to track for multiple vendors. Created “VINCE”
- VINCE = Security vulnerability issue tracker designed to support multiple affected suppliers/projects & multiple relevant researchers (most issue trackers only work for one supplier), enables private reports/discussion, web-based instead of email-based.
- Someone can file a ticket; they can then decide whether or not to accept that ticket; if they accept the case, they can notify other vendor as part of “case discussion”
- Coordinated disclosure practice we have been doing with a mismatch of tools, lots of email, PGP, GPG, lotus notes… They have been looking for a better tool solution - nothing off the shelf fit. They decided to go with custom build.
- VINCE (https://www.kb.cert.org/vince/) program started in end of May
- Internet facing tracker with security and privacy
- Multi Vendor component was a major limit preventing off the shelf
- The bugs have dozens to hundreds of vendors - they need to track if each person has responded if they are impacted and if yes if they have patched it
- Modern option Bugcrowd or HackerOne
- Only CERT runs VINCE, plans to open source it and let others run their own copies of it
- People can submit a bug, logged in or not (anon)
- Each day go through tickets
- Triage daily
- Ideally conversations happen within (https) vince, want to move away from PGP and email
- Case opened, invite vendors
- All vendors know who is in the case
- Coordination for a vulnerability happens here
- This is also content tool (they call it a vulnerability note)
- Overall they are open to anyone submitting anything
- They pick cases based on where they can put most value
- Many vendors handle their own cases (more and more over the years)
- Multi vendor cases don’t have an easy answer and that is where they focus (upstream when many share a common tech)
- Emily Demo (vince - vulnerability information and coordination environment)
- Submitting vuln report
- Showing the ticket those come in as
- Will either take it (make a case) or not (may just need to provide reporter contact information for a vendor)
- Case - in vince com - is where discussions happen, similar to a message board. You can tag the report and ask for more information for example. That will send an email notification.
- Ask vendors to state their status (affected)
- VINCE: https://www.kb.cert.org/vince/
- https://vuls.cert.org/confluence/display/VIN/VINCE+Documentation we plan to open source VINCE
- Question: have others asked to run this? Yes they have had interest. This will be an option when this becomes open-source.
- Next steps build our API further and what does a common API coordination tool look like?
- @stevespringett Showing how SBoM supports vulnerability remediation tracking
- This is how CycloneDX does things today
- They do standards development
- Risk first
- The default schema is only static factual data and it is extensible.
- The extensions provides optional capabilities (such as vuln disclosure) for things that change over time.
- Security first SBoM spec
- Supports remediation and disclosure elements
- Component Remediation
- Can denote a patch versus upgrade, and say which vuln a patch resolves
- Does not try to communicate effectiveness of a remediation (it’s an opinion of someone at a point in time)
- Does not describe build, runtime, or environmental remediation - out of scope for spec
- Vulnerability disclosure
- A component can be impacted by multiple vulnerabilities (using an extension)
- Refers to package url - cvss v2 or v3 and other risk ratings supported
- Disclosure notes
- Vulnerability extension communicates instances of vulnerabilities
- Vulnerabilities can only apply to a single component
- Possible risk rate each instance independently
- May increase BoM size as you are unable to reuse vulnerabilities
- They are working with Snyk to improve
- Note: there are many incompatible formats for describing the vulnerabilities, we may as a group want to look at this. (we do have a task to compile our list then look at similarities and differences)
- @MarcinHoppe: we also need to indicate what pain points (use cases) are being addressed in addition to formats
- Art's list of formats - https://docs.google.com/spreadsheets/d/1vq1hXLPusfcLstSCGYrzRYkI3qeeEj_hLVipJBgoWEA/edit?pli=1#gid=0
- @kerberosmansour list: https://www.ten-inc.com/ise/northeast/default_2017.asp (The Vulnerability Scoring Model (VxSx) Project)
- @dcmiddle - is working with other OSS groups and is trying to pair up contributors and groups (requirements from the real world) - captis? Young group found they don’t understand vulnerability disclosure - need one to two volunteers monday 6pm pacific to show up and help them out. Reach out via slack or email - [email protected]
- @kerberosmansour raised an issue in OWASP dependency Track jeremylong/DependencyCheck#2958
- @dcmiddle open issue to look for volunteers to share disclosure best practices with the Cactus OSS project (#77)