Webinar: Why Cloud-Native Applications and APIs Are at Risk

A Bug is a Bug is a Bug: Security Bugs are Just Bugs

Let’s just face the fact there is no such thing as a perfect application. All applications have bugs and will continue to have bugs because as soon as one is fixed a new code release introduces a new set of bugs that also need to be fixed. Companies use terms like “hotfixes” and “point updates” to gloss over fixing bugs in their applications.

Where did the term “bug” come from?

As an industry, we have adopted the term “bug” to reference something that is not working correctly in an application. Phrases like “that application is full of bugs” or “we need to debug that issue” are used all the time but do you know where the term came from? Well, it was an actual bug – well a moth to be more precise. 

The Origin of the term Computer Bug’ provides a great history lesson on the use of the term “bug” in technology all the way back to the 1800s. The article states that “Famously, the very first instance of a computer “bug” was recorded at 3:45 pm (15:45) on the 9th of September 1947. This “bug” was an actual real-life moth, well, an ex-moth, that was extracted to the number 70 relay, Panel F, of the Harvard Mark II Aiken Relay Calculator.”

The ACTUAL first computer bug

Source: U.S. Naval Historical Center/Wikimedia Commons

Bugs are a way of life in applications and infrastructure development

Fixing bugs in your applications or cloud infrastructure is a major part of the everyday activities of your development or infrastructure teams. There is no such thing as a bug-free application. Organizations go as far as offering financial rewards to ethical hackers on Bug Bounty programs to identify unknown bugs. Once a bug is found it needs to be fixed. 

Organizations have a clearly defined, and accepted process to remediate functional and configuration bugs, but everyone freaks out when a bug is labeled as a security bug. Security bugs can create a very subjective, and sometimes heated, conversation between application development, security, and architecture teams. Why is this?

Security is a scary word to developers

Development teams are very familiar with functional and configuration bugs as they are logical in nature. In a functional bug, a specific functionality in the application does not work correctly so the code needs to be fixed for the functionality to work. For example, a submit form button does not submit the form correctly. 

In a configuration bug, something is wrong in the applications configuration, so it does not run correctly. For example, a production application is configured to pull data from a development database. 

A security bug on the other hand is not as black and white to a developer. They do not always understand the risk associated with a security bug or why someone would use the application in a strange and unintended way. This lack of understanding creates confusion and usually leads to some sort of “prove it” statement by the development team to the security team.

Why are security bugs treated differently than functional and configuration bugs?

This is an easy question to answer: lack of context. Functional and configuration bugs can be very complex to fix but the goal is simple, make the application work correctly and as intended. Security bugs on the other hand can be very obscure, difficult to understand, and only happen when an application is used in non standard way. 

Security bugs in applications are typically associated with some sort of standard like OWASP Top 10, or a CVE. Some examples of security bugs are SQL Injection, Cross-Site Scripting or Cross-Site Request Forgery. The problem with these types of security bugs is that they look at the issue as a self-contained entity and not how the issue relates to the complete application architecture. Just fixing each of these security bugs as unique entities may hide underlying architectural flaws in your application.

By providing full application architectural context to security bugs development teams can better understand the entire threat landscape of their application and how security bugs could be executed. Having full application context is key.

Application Security Posture Management to the rescue

When an application is managed by ASPM solutions like Bionic developers, security teams, enterprise architects, and site reliability engineers, they are provided with complete application architecture risk context. This full context allows development teams to work with these other teams to better understand the security issues they are assigned to fix. ASPM allows developers to have the same information about security bugs as they do with functional and configuration bugs.

Why should I care?

Bugs, no matter what type they are, need to be fixed. Today’s CI/CD pipelines are releasing code to production faster than ever. More code changes to production environments means more potential bugs which need to be fixed. With ASPM it is much easier to remediate all types of bugs through the same process and context. Having a separate process to remediate functional and configuration bugs vs security bugs does not work any more.

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

See a Live Demo of the Bionic Platform