The importance of software BOM for hardware security

Hello Oleg,

interesting thoughts. Integrated product structures made up of a combination of mechanical, electrical and software design is one of the most challenging requirements for PLM. On one hand there is a “clash of cultures” between more conservative mechanical engineers and progressive software programmer. Mechanical engineers design physical objects which must fit together mechanically; most of them loves the sunlight, working during the day and knows the difference between broccoli and carrots. Software programmers designing virtual things you cannot touch but doing impressive things, I’m not sure regarding sun light resistance of them, they working during the night and know all pizza service phone number by heart.
Ok, little bit stereotyping and not meant so serious.
On the other hand there is the difference in the dynamic of “changing cycles” during the product development. The life cycle time is different and difficult to synchronize. A new revision for mechanical assemblies can take days or weeks, a new revision of firmware or another piece of software can take hours. Changes in physical structures needs some coordination effort (collision detection, DMU, FEM etc. pp.), changes in software needs (in best case) only some minutes to running automated tests.
In my opinion it is not possible to convince software programmers to give up working in SW-Engineering specific IDEs like Eclipse, Visual studio, Netbeans and others. I don’t know a PLM system which has the broad functionality to support programmer’s daily work.
But it is possible to integrated the working results in a combined product structure and synchronize pizza and broccoli 😉 into a common product structure tree. With working results I mean software releases, compiled code, running binaries – something like this. And of course you need a link to the source code version, on which the release is based.
That’s my 50 cents on this discussion. But maybe someone has made other experience. I am looking forward to discuss it.

Christoph

The article you reference also directs readers to a free source for creating a software bill of materials. Whereas manual efforts could take hours or days, there are a number of free (and paid) tools for creating a bill of materials — some of which produce the BOM in about 5 minutes, while others may have turnarounds in as few as a couple of hours.

BOM vary in terms of information provided, including the name, version, age, popularity, license types, known security vulnerabilities, dependencies, etc.

In the paid category, I know that Veracode, Sonatype, and HP Fortify all have offerings. In the free category, their are offerings from OWASP (see OWASP Dependency Check) and Sonatype (see Application Health Check). As with all offerings, the paid versions often include more functionality than the free alternatives.

In reference to breaking down the silos, I think that is really a matter of a more sophisticated type of supply-chain management. At this point different people, tools and processes can feed the creation of an overall bill of materials. Where the physical bill of materials has been done for many years, the software bill of materials is something that is relatively new. Support for software bill of materials has been aided by the dramatic increase in use of identifiable and traceable open source components used when assembling modern apps today (many suggesting that OSS components make up 90% of an app).

I hope you found this perspective helpful.