One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 992101 |
| Date de publication | 2019-01-14 16:28:00 (vue: 2019-01-14 20:01:15) |
| Titre | Software Bill of Materials (SBoM) - Does It Work for DevSecOps? |
| Texte | There has been much discussion of a “software bill of materials” (SBoM) lately, for use when addressing security vulnerabilities. Many are curious, wanting to learn more. Googling the term gives lots of positive descriptions. This post will go negative, describing problems with the concept. Rather than cover the entire concept, I want focus on a narrow part of it, so I asked Kate Brew to write a short blurb why she’s interested in SBoMs. Her response was: “I am an Industrial Engineer by training. So when I heard of the concept of software BoM I was intrigued. Being able to quickly see all the components, open source or not, incorporated into an application appears like a valuable way to determine needed actions in the case of vulnerabilities found in a component. It seems efficient and helpful to me to have a clear view of components in an application.” Software is never built wholly from scratch these days. Instead, software is built combining components, development frameworks, libraries, operating system features, and so on. It has a “bill of materials” describing the bits that make it up every much as hardware does. When vulnerabilities happen, knowing this information can help. Good examples are the high profile Apache Struts bugs, where customers don’t know they are vulnerable because they are unaware that products they own include Struts. If only product vendors provided a list of sub-components, then customers would quickly know if they are vulnerable, and be able to act accordingly. Some claim this sort of thing already exists in narrow industries, like medical and energy. They are pushing the concept for use everywhere because it’s already being used successfully somewhere. This is a great story, but it isn’t true. Software Bill of Materials Is a Misguided Concept for DevSecOps Proponents are being deliberately vague defining exactly what should be in included in a software BoM. For hardware BoMs, you don’t list the ingredients of the circuit board, where you sourced the silica for glass fibers, or the recipe of the epoxy that binds them together. Hardware BoMs aren’t that granular because it’s not necessary. They include an indented list of components and sub-components. Hardware is basic. But when tracking software vulnerabilities, such granularity is important: you need to track every line of source code. There are four levels of details for SBoMs: Licenses Modules Patch levels Backports Most of the discussion about SBoMs is roughly at the license level. The makers of software already track this, even when they don’t disclose it to customers. Commercial products track this for legal reasons, for compliance with legal contracts they have with suppliers. Open-source products track this for practical reasons, since you often have to hunt down install the dependencies yourself in order to make open-source work -- importing open-source implicitly means importing the license. You see the artifacts of this everywhere. My parents just bought a new Subaru, which like most new cars contains a small screen for the maps and backup camera. On one of the pages on the screen I find something that lists a number of embedded components. Displaying this information is often a requirement of the license. Software Bills of Materials Aren’t That Great for Tracking Vulnerabilities SBoMs aren’t as useful as you’d think for tracking vulnerabilities, because it’s not granular enough. Take Linux, for example. The entire thing is licensed under the GPL. This hides the complexity that the kernel is around 20 million lines of code, and the GNU userland components are millions more. An SBoM saying this IoT product uses “Linux” hides a lot of the complexity of what may or may not exist in the product. A new Linux vuln is discovered at th |
| Envoyé | Oui |
| Condensat | “guns 2014 about actually agrees airplanes airport airports/story all already also analysis analyzer anyway apply applying are aren’t attacks audits automatically back bad because being bill bills binary block blocked” bom bug but can can’t cannot case ceo challenged cherry claims clients code com/us/tsa comes companies component conclusion: crappy deeply describes determination determine development devsecops disclosure do does doesn’t dubious duty either enough ethically even every everyone exactly example example: exist expensive exploitable fact fails far feature feel figure find firearms firewalls flawed forcing form formerly from fudged get getting gives going good gov/blog/tags/year gpl granular has hasn’t have heartbleed help hide how https://abcnews https://www i’m id=51022188 imagine implication independent information internally isn’t it’ll it’s its katie latest let level license licenses life like list looked lot make management manager match matching materials means measurement microsoft microsoft’s miss missed missing mitigations module modules months moral most moussouris much nearly necessarily need needed nobody not notices numbers often ones only openssl operation options oracle other out overspend own package packages partial passenger patch patches people picking places pond possibly post practically practitioners problem processes products program programs publish rather reach real really recommends regularly rely review same sbom sboms screeners screening security see server services show side similar simply simultaneously since situation software solution some specific spend static struts stuff subcomponent success successful successfully such system tell tests than that’s them thing things those thousands through through” time today took track tracks try tsa two type unappealing undercover unnecessary unneeded upon use used useless users using vendor veracode violation vuln vulnerabilities vulnerability vulnerable way weed weld when whereas whether which why will without won’t words work works would years you’ll your |
| Tags | Vulnerability |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.