The End of Wild West Software Development

Published On: Dec 6, 2023

I think we’re getting close to the end of the wild west of software development, we’ve been moving this way for a while. The days that someone right out of a software developer bootcamp creating the next startup app that takes the world by storm, at least the business world, will most definitely be done within the next five years. As an application security practitioner, I don’t think its a bad thing, but it does signal that there are going to be tough days ahead. How did I come to this prediction, let me connect the dots for you.

I think the first of the major events that have turned us in this direction was the Executive Order about software bills of materials. "(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;" This was the first time that I saw anyone outside of the AppSec Community talking about SBOMs, reception outside of the inner circle of people seemed mostly lukewarm.

The interesting part of this is that it seems that there are lots of groups that are now attaching themselves to this through a knock on effect. The trick is that all of the ecosystem is interconnected, and because of that it means that people who are getting asked about SBOMs now feel empowered to ask their suppliers for SBOMs. Inclusion of software bill of materials as part of the security process now means that some of the darker secrets of software development teams are going to be brought into the light, more than likely during the sales process or during the contract negotiation. If you haven’t been asked for a SBOM Yet, your time is coming. The days of building software with out of date components are quickly coming to an end. Again from the projection space, I think there is going to be a very clear line that is not going to settle well with a lot of people in the board room, because now their development process is under scrutiny, and the result is going to either be a failure to sell or a significantly lower sale point (with the understanding that the customer is going to have to put in place mitigating controls). Personal experience tells me that there are two different types of development teams, the ones that are utilizing rolling builds with extensive test suites and those that have libraries that were included in the initial deployment of the software.

“The guidelines shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.” (Section 4.b EO above) This is interesting since we are now seeing documents released from the largest list of signatories that I have ever seen in the application security space, with the release of the CISA Security by Design papers. (If you haven’t seen it lately the number of people signing up has actually grown and now includes: CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NL NCSC-NO | NÚKIB | INCD | KISA | NISC-JP | JPCERT/CC | CSA | CSIRTAMERICAS.) Nothing in the document is outside of what we have been talking about in the application security space for years, but the weight that’s now behind who is saying it has changed a great deal.

“The security and integrity of “critical software” — software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) — is a particular concern.  Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software." (Section 4.a)

Another interesting development in this is that CISA has now released a self attestation form, and for a long time others (and myself) have laughed at the idea’s of self-attestation. In most cases they are signed by people from the sales process who have no idea what they are filling out. But this one is a little different… as it includes the following line:

“d. The form must be signed by the Chief Executive Officer (CEO) or Chief Operating Officer (COO) of the software producer. The signatory must be an employee of the software producer. By signing, that individual attests that the software in question is developed in conformity with the secure software development practices delineated within the form. The software may be used by a Federal agency, consistent with the requirements of M-22-18, as amended by M-23-16, once the agency has received an appropriately signed copy of the form” (Secure Software Self-Attestation Common Form)

Pair of this with the list of signatories for the secure by design and secure by default initiatives that are currently being carried out by CISA. The reality of all of this is that if you are doing business with the government or (and almost more importantly) any one who does business with the government (that’s how supply chains work), are going to have to expose not only the way that the software is being built but what the results are. Since it’s going to have the CEO’s (or COOs) name on it I can imagine that there is going to be some scrutiny from not only the C-Suite but the Board as well.

Take this in combination with the fact that CISOs are starting to be held accountable, although lately at a legal level, for the acts of businesses getting hacked. One only has to look at what is going on over with Solarwinds SEC Charges to see which way the wind is blowing. In addition there are some interesting points in those charges that bear, its interesting to note that they are taking into account not only his time in the CISO chair but the times before he held the title. This is an extreme case, but if you look at this article from Forbes I think its becoming clear who is going to the bigger target on their back. That being said you notice that they aren’t asking for the CISO’s signature on the self attestation form.

Take all of this together and I don’t think the way that software development has been operating is going to be feasible anymore. While there are a lot of really good developers out there who are working really hard to keep up with the processes that ensure good application hygiene (remember security bugs are just bugs), I think you are going to see a wall going up between those developers and their counterparts. I would be surprised if there isn’t an OSHA like organization for dealing with software development by the end of the decade.

… And again, it’s probably overdue.

As always, these represent my thoughts not the thoughts of my employer. If you would like to hear their take on things I would direct you to contact their PR department directly.