I am a Software Developer with a passion for Security, ALM, Agile, and Coding Practices. I have been working in .NET as a developer for over a decade, a network admin for years before that. I have worked for large companies and small ones, many that you would recognize some that you probably interact with. I am opinionated and deeply curious about the world. If you have a problem there is a good chance that I would be interested in hearing about it. More than that I want to help others, mostly because I believe that helping a single person raises the quality for everyone.

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.

Developer security is a wholistic view of the applications security, it’s been something that I’ve been working on for several years. The problem with application security is that inherently it focuses on the product, the application. The alternative approach seems to be DevSecOps, where we make security part of the operations session, indeed shifting left from the application to the build process but really I think that this is still missing something. Since we are still focusing on the output of the process and not the process itself.

Inherently if we are looking to improve security we have to go to where the security issues get into code, the developer. To accomplish this most of the focus for the moving pattern is going to have to be placed on the education process and the management of the measuring where you are in the process. Education is pivotal because it is designed to change the mindset from our attackers are super elite hackers, to the majority of the attackers that we are seeing are people who simply have more time to dedicate to the focus of security (squirrels). In this way we have to figure out how to take all of the time that the attacker would focus towards attacking our site and focus it into the defense of the product that we building. This approach puts a heavy amount of thought and work into the developer, and what their workflow looks like. The goal of the process is to get the developer to focus in on what they are developing and ‘develop the attacker mindset’ (more on this in a moment).

Okay now on to the elephant in the room, developers aren’t attackers, and telling a developer to think like and attacker is like telling a developer to think like an elephant. Inherently they can’t do it, because it’s not their frame of reference. That’s okay, instead we want to shift their focus from thinking about security to thinking about resilience and safety, because on the Venn diagram of security those are the overlapping pieces that allow for a common mindset. Once we have that in place it’s a very small jump to the next level to make sure that we are accounting for the, ‘what can go wrong?'. Once we get to this mindset I think that we are in the sweet spot for moving forward.

So how is this going and what are some of the main things that we have been able to do to figure out where we are going and what we are doing as part of the process? Short answer is that so far things are going okay, it takes a long time to boil the ocean and there are a lot of tasks that we have to focus on as part of the process, there really isn’t anything that we can do to get around that. This is one of those ‘We do these things not because they are easy, but because they are hard’, it is the right thing to do.