Last updated at Tue, 25 Jul 2017 18:32:42 GMT
In the PCI newsletter #14 we discussed why bugs aren't fixed in software before release.
Once software is released and installed within our environment these weaknesses are on our side. Is it a problem?
Examples:
Let's take the image of a bridge, a strong and proud bridge. Cars are driving through it the whole day without being aware of the presence of a weakness in its internal structure. In appearance, no threat, no risk. And then there is a fateful day when an earthquake intensively shakes the city. While the bridge was supposed to resist this intensity, it failed and collapsed, sweeping along a dozen cars and their passengers into the river.
A sudden tragedy revealed the hidden threat. Of course, if people would have known about the weakness they would probably assess the associated risk and block the bridge, right? Well, I'm not sure because taking such a decision would have had a huge impact for the city. This is related to the decision process and is the subject of another newsletter.
Let's take a second example...
Imagine that you stand in a humid spot infected by mosquitoes and that you are allergic to their bites. Fortunately your entire body is sheltered under your special gear. However you didn't notice a tiny tear. Tiny but big enough to let a mosquito bite you. The consequence will depend of how much you are allergic to mosquito bites. The merchant you bought it from would not replace your gear, but suggests you sew it up or stick on a small piece of material to patch the hole.
The consequences of software bugs in our environment
The presence of software bugs or holes within our environment could create a whole set of issues such as preventing legitimate users from accessing functionalities; impacting the performance and usability; crashing services or servers; leading to confidentiality breaches; escalating user privileges; soiling data integrity. Is this a problem? Well it depends of the severity of the bugs (what the bug could lead to) and the criticality of the environment on which they run.
The same bug could reside simultaneously on a production server and a test server. The same bugs will have the same consequence on both servers such as leading to crashes, but the criticality would be more important for the production server than the test server. This aspect is of the utmost importance when considering a remediation plan. But before fixing a bug one must detect it.
As said in the previous newsletter, bugs could be known or unknown. They could be detected accidentally or through code analysis and application testing. They could be detected by company developers or testers, by the users or by malicious individuals looking for them. Once known they should be fixed. This fix generally consists in writing a small piece of software called a "patch" in the same way the merchant or tailor would apply a patch on your gear.
I'll let you decide how you would look if your clothes consisted of as many holes as there are in software. Maybe this could become a new fashion.
Once bugs are detected and fixed on the software company side, they still need to be fixed within our environment and that's another story.
Questions
Did you find this article useful?
What was the most severe consequence your company experienced that was caused by the presence of bugs?
