Software Is Assembled

Robert Vamosi
August 17, 2021
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

It's important to understand that there is no 100% in security. Frankly, it is impossible to secure everything all the time. So more often than not, we're putting obstacles in front of an adversary, so they go somewhere else. That's not defeatist; that's reality.  

What you're really trying to do is balance the value of what you're protecting against the effort required to break it. Let's say you want to defend your house. You put locks on your doors but they can be defeated. What about Windows, someone can smash a window and still get inside. Maybe you put a security system in place, but are there blind spots. Short of building a moat in erecting a very high wall, there's always a way for a determined adversary to break into your house.  

It's just a question of how hard it is to do so. And how many barriers you feel comfortable putting into place. The situation with software is similar. You can't realistically fix all of the software vulnerabilities, but you can try and find and fix an increasing number of vulnerabilities to make it more reliable and more secure, along the way. 


Today software is assembled, not written, meaning software developers are more likely to stitch together other people's code, and write it themselves. This is what gives us the rich features that we've come to expect. 

You can think about it this way, software applications are constructed in a way similar to automobiles, individual components are sourced from multiple vendors that then are stitched together to produce the final software that's released to the customer, software applications today contain hundreds of code components, and these can come from a variety of sources. 

It's estimated that, 85% of modern applications are made up of third party components, and those third party components may include the free and open source software or commercial off the shelf software developed by external individuals or organizations. It is not out of laziness that third party code is used. In fact, there are a variety of benefits to using third party components. Using third party components gives developers the boost they need to keep pace with the ever increasing development speeds. Outsourcing parts of your product to the experts often results in a higher quality output. 

For example, if your organization wants to use TLS protocol for securing communications, it is much much easier and safer to use established third party components, such as open SSL open software can be free of licensing and therefore free to use. This allows developers to release faster without having to code features from scratch. 

So open source fulfills the criteria that must be met for them to efficiently complete their work, but it's folly to think that open source software or consumer off the shelf components are not without their own vulnerabilities. Software vulnerabilities can be inherited through your software supply chain. And that's way more common than we care to admit. 

Since 2014, The National Vulnerability Database has reported more than 6000 New, Open Source vulnerabilities. Part of that as a result of an effective effort to retro actively test and secure open source products

That's third party vulnerabilities. What about code vulnerabilities that you, and not the third party introduce? Unfortunately, even primary code can suffer from code vulnerabilities. 

Download: Fuzzing 101: Application Security

See how you can use fuzz testing to locate unknown vulnerabilities before your adversaries do.

Download the Whitepaper Watch on YouTube


Overall code vulnerabilities can be divided into three distinct groups. 

  • Known knowns are code vulnerabilities that are widely available to everyone in the industry. Usually though if you hear about a known vulnerability, it has a CVE number associated, and these can be easily mitigated.
  • Known unknowns is where we recognize the general shape of a vulnerability, but haven't yet found it in the code itself. This of course requires access to the source code, known knowns and unknown knowns, are much easier to defend against because at least some part of it is known. 
  • A third type then is unknown unknowns is a third type and is also the most dangerous because almost nothing about these are known.  Unknown unknown vulnerabilities are also known as zero days, because the vendor has had zero days to guard against it. If an adversary or other malicious person finds an unknown unknown vulnerability and develops the exploit for that first, then by definition, nobody has any defenses for it. On the other hand had that software vulnerability been caught and found by the internal software development QA testing team, it could have been fixed before the release, and the whole thing would not have been an issue.   
Share this post

Fancy some inbox Mayhem?

Subscribe to our monthly newsletter for expert insights and news on DevSecOps topics, plus Mayhem tips and tutorials.

By subscribing, you're agreeing to our website terms and privacy policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Add Mayhem to Your DevSecOps for Free.

Get a full-featured 30 day free trial.

Complete API Security in 5 Minutes

Get started with Mayhem today for fast, comprehensive, API security. 

Get Mayhem

Maximize Code Coverage in Minutes

Mayhem is an award-winning AI that autonomously finds new exploitable bugs and improves your test suites.

Get Mayhem