Software Bill of Material (BOM) Value

A Bill of Materials (BOM) for software affords the following benefits

  1. Licensing – each components licensing requirements can be identified & approved
  2. Vulnerabilities – component & application risk can be assessed
  3. Reduced debugging – known versions ensure consistent execution by developers, testers, & production

Any complicated product has many components & sub-components. Open source usage with the free availability to include, update, or remove components presents a large risk to the company. The development team should be able to quickly answer basic questions:

  1. Provide a list of all component license agreements
  2. What is the highest CVSS score of the components & what is the plan to reduce this exposure?
  3. What is the impact to updating a component to a new version?
A product or component BOM should contain enough information for the team to manage (hopefully pro-actively) development, in spite of daily concerns: management requests, new updates, team turnover, alternative design considerations, etc. Each component’s BOM should be in tracked at it’s highest level via source control.
BOM Items for each sub-component:
  • Name
  • Version
  • Author / Organization
  • Source website
  • Source license URL
  • A copy of the license (probably necessary if not an standard license)
  • Reason for inclusion
  • Responsible person
  • URL to it’s CVE disclosure list (for example, Tomcat is pro-active:
  • Risk discussion – it’s common for vulnerabilities tracked in to have a high CVSS (, but not be applicable to a component’s usage. For example, an openssl vulnerability with signature generation may not affect the product if openssl is strictly used for secure communication. This should be clearly documented with analyst name, date, & discussion for each CVE.
Candidates for BOM-like tracking: product software, build machines, test computers, & deployment platforms. For example, the build machine should be a strictly controlled resource with documentation to support employee hand-off with minimal disruption. If the creation/provisioning of a new build machine takes more than a couple of hours, the company has a significant risk.

The unfortunate part of this proposal is that it is non-trivial. Implementation requires time, effort, and discipline. On-going maintenance has a similar burden. However, creating this retroactively is much worse – I’ve been there, done that!



Software Bill of Material (BOM) Value

A Really Good Read: “Win Bigly”

Win Bigly: Persuasion in a World Where Facts Don’t Matter by Scott Adams

Scott is far deeper than whom we closely associate him with: Dilbert. Adams has a long-standing blog that is very popular, as well as Twitter, Periscope, etc. He’s written a couple of books & I’ve found both helpful & enjoyable.

“Win Bigly” presents reality very simply: there is no reality.

Seriously, my reality has zero relationship with yours. And vice-versa. There is tons of data to support this, which he presents.

So what? The answer is given this starting point of “no reality”, how does one influence others? It turns out there are many guidelines in this book that help in many situations. A very good “business read”.

A Really Good Read: “Win Bigly”

So You Want To Change the Culture?

Many find a new corporate culture attractive and try to make it so. Before starting that journey, there are a couple of prior changes you may find helpful: the Semmelweis Reflex & Donald Rumsfield’s U.S. Department of Defense update for Special Forces.

Ignaz Semmelweis was a pioneer to champion hand-washing as a standard part of medical treatment in 1847. Twenty years later Louis Pasteur postulated the germ theory, which sped things along. Semmelweis had hard data to support the change, but the resistance to change was massive. Consider the suffering & loss of life before this simple change had wide-spread adaption!

It has been said that science advances one obituary at a time, meaning as the old critters die off, the young replacements aren’t so wedded to the “proven” ways. From a change of culture perspective, one can counter the Semmelweis Reflex with natural attrition.

United States armed forces started building “Special Ops” forces after the Iranian Hostage crisis in the mid-1970’s. The very top brass resisted in many ways over many years in developing these units into what we now take for granted.

Donald Rumsfield didn’t have the patience to wait for natural attrition. As the Secretary of Defense, he had the vision & drive to affect the change in leadership that could bring about this change. It took a couple of years, but he was able to bring in the correct leadership to get the job done.

Culture change can be accomplished in both ways, however I like a quote from my friend, Erik:

“You can change people or you can change people. I prefer to change people!”

It’s up to you.

So You Want To Change the Culture?

Safe Software

Software developers, manager, and teams tend to dislike analogies to traditional manufacturing, because we’re “special”. And many will argue that we’re special in soooo many ways!

When one purchases an automobile, what concern do you have for the safety design reviews? What about their costs? Clearly it takes time to conduct such. The crash-worthiness tests are similarly expensive both for the time & the capital expenditures. Yet, as purchasers, we don’t give a wit.

When it comes to software development, adding software security to the analysis, design, coding, testing, and reviews is often strongly resisted. After all, it takes time to perform this work. And additional time means less features. (If a customer doesn’t have feature X, he’s not going to miss it’s non-delivery. There already is a work-around.)

However, as with automobiles, customers have a certain expectation that the software is safe to use. (I’m not speaking of medical, avionics, or nuclear power plant software; rather traditional office or home software.) If a vulnerability exposes all of your customers customer data to the internet, methinks an expectation of safe, secure software has been blown to pieces. It doesn’t take many reports for your brand to be tarnished beyond repair.

So then, why the resistance to secure software? One reason may be that many in the chain of command have put together well-crafted product plans and a successful delivery means great bonus compensation. The implementation of new, aggressive security testing, analysis, design, training… ugh. And after all, we’ve never had an issue before, right?

People are people and most people strongly dislike change. Even the vaunted “cutting-edge” programmer title we like to bestow upon ourselves doesn’t mean we like change. Many programmers don’t like change. And for a variety of reasons. However, safe software and the associated culpability preclude dawdling; we, as a group, have to demand the time to do the job right.

Consider asking an architect for an estimate to build a bridge. When it comes back at $10M USD and 1 year to build, one impulse is to say: “Cut the cost & time by 1/2!” Professional architects will simply bid you “Good day.” Programmers, on the other hand, will say: “Sure.”

Unfortunately, they often do just that.

Safe Software

Hoarding Code is Technical Debt

The idea seems so innocent: a feature is no longer needed or is obsoleted, but what’s the harm in leaving it? For a visual of this, consider any of the “Hoarders” episodes on YouTube. What is the harm in keeping this old cuckoo clock? How about this old skateboard? Mcdonalds bag?

The years go by quickly and soon no one has any recollection of why that feature ever had merit. But then, there may be some customer that has some odd requirement that needs this feature – we think. (And, for sure, Junior will be stopping by to pick up his skateboard.) There hasn’t been a bug recorded against this, so it can’t be broken, can it? (The cuckoo clock hasn’t worked in years, but no one complains.)

Unfortunately with software there is a cost to this old junk. The cost is repeated re-learning what this does, coding around it, and occasionally designing & testing it. A great feature would be documented; a good feature would be obvious to end-users and pretty plain to see in the code; the rest is probably junk. What’s the old rule of thumb? 20% of the code fulfills 80% of the need?

From a security perspective, code adds “attack surfaces”. The more code, the more opportunity for bad things to happen. The opportunities for what can go wrong can get sizable very quickly.

Let’s revisit the hoarder’s analogy for a moment. After some time, a new, sleek hot-shot feature is incorporated into the product. Kinda like a new modern, contemporary house being built next to said hoarder’s house. What is the value of the new house? Has the hoarders dump reduced the net gain? From the customers perspective, why would it be any different?

Let’s keep our code (product) lean & trim!

Hoarding Code is Technical Debt

New Code vs Maintenance Code

Working on new code is fundamentally different than maintenance. When one is buried in maintenance, it’s easy to loose site of what it means to have no design constraints, other than the best for your situation.

When doing new code, you have to think about best structures, algorithms, classes, interfaces, etc. Take this mindset back to the maintenance side of the house and  what happens? You’re stunned at what is in front of you. It looks like hubris. But now you know what is possible and can re-define success.

For this reason alone, it is intellectually refreshing and important to take on small projects. Like a Raspberry Pi, for example.

New Code vs Maintenance Code

Roofing Your Garden

Last year our garden had weeds growing between the boxes. A thick covering of shredded trees (wood chips) looked good, but didn’t do a thing for keeping the weeds under control. It’s just nice to have no weeds, but wedding the walk-ways seems too much. 

As it came to be, a shed needed new shingles. This generates waste – the old shingles! Rather than just toss these out, how about roofing the garden or walk-ways?

Last years wood chips were pulled aside, the old shingles laid down, and the chips et al back on top. This should keep the weeds down and make the garden look much better, without more weeding for a long time. 

Roofing Your Garden