Responsible disclosure is a sham.

I saw it again in my posts today, and this time I can take the gloves off, so here is a hot take that I’m sure no one will enjoy.

Hackers / Security Researchers do not OWE businesses anything; responsible disclosure is a sham.

The main crux of the argument that I am going to make here is that providing responsible disclosure and a timeline window continues to coddle business exceptionalism and allows some of the more wretched application security practices to continue.

The core of the reason that groups need that large a window to address issues is because of the following items:

  1. Many of the libraries that are included in their software are only updated when there is an issue. [in ability to remain current]

  2. They lack proper testing regimes to feel comfortable about the release of software. [lack of automated testing]

  3. There is a complicated deployment process that requires outage widows that can’t happen during business hours or need to be scheduled weeks in advance [bad CI/CD practices]

  4. If we must notify our customers that there has been a cybersecurity incident that will look bad on us.

Fundamentally development solutions that fall into the categories above are hard to work on, developers (not the management) generally pays the price of having to address these issues, often having to extend hours, and waylay other tasks to overcompensate for the failure of process. I have seen the business team prioritize short term goals over the stability of software so many times that it’s hard to stomach, which is more often the root of these issues.

Libraries should be updated en-mass at the beginning of the sprint. This is good hygiene, this ensures that any issues that arrive are delt with in an appropriate amount of time. This keeps the work needed each sprint to the lowest possibility (since you are only dealing with point release changes). If you are doing this an update to a cleaned version of the code base is a single sprint away, EVERY SINGLE TIME.

There is no replacement for adequate automated testing, and the worst programs that I have worked on over the last 20 years are the ones that have little or no unit testing. For me this is the best indicator of it the project that I’m going to be working on is going to be a nightmare. Projects that don’t have good unit testing usually have multiple parts of the code base that fall into the ‘don’t touch that, no one knows how it works’ section of the code.

CI/CD is hard and that’s why we have quality DevOps people who are competent and well trained on the technology, trained on multiple environments, and are allowed to implement processes that ensure that there are no deltas between environments. Another one of the good indicators of a ‘fun time’ is that tools like ansible, terraform, etc. can’t be implemented because ‘this environment is different’. I have met so many DevOps people who are burnt out because there isn’t time to do something the right way, but somehow there is more than enough time to do it over and over again the wrong way. Utilization of tools like Kubernetes and A/B deployments have been around for almost a decade now, these tools implemented correctly can ensure updates and uptime.

As for the last item in the list… guess what, everyone is in that same boat and we as a community need to get way more comfortable talking about what has happened and how we dealt with the situation. The days of being able to fly under the radar are gone, if you utilize open-source software you are in the same supply chain as everyone else. If the C-Suite can’t understand that, the comet is coming for them (http://bit.ly/3U6LveV).

Businesses will continue to say that they need the 90-day disclosure windows so that they can protect their ability to protect their customers. But it is allowing them to continue to practice the bad development practices, which continues to propagate broken processes that leads to developer misery. The 90-day disclosure period props up bad software development practices, usually for the dollar takes all mentality crew.

They believe that having to release a quick update is something that will make them look bad, the reality is the inability to release a quality update quickly is what is making them look bad. Never mistake the difference between those two things.

These are generalities, but I firmly believe that there are more groups that would like to believe that they are the exception to the rule, than are genuine exceptions. If you are interested in getting to a place where these things are possible, please reach out. I would love to talk to you.

Next
Next

Protecting Your Business: The Vital Importance of Backups and the 3-2-1 Rule