Coders Conquer Security: Share & Learn Series - Using Components with Known Vulnerabilities
What is the one thing that all applications have? Components, also known as dependencies or libraries. There is very little code in the world that doesn't depend on other code at some point in time. You even start with a mountain of dependencies from the time you create the application!
Since all applications use components, most of which you haven't written, vulnerabilities within the components you use can become liabilities. Let's discuss what using components with known vulnerabilities means, how dangerous it is, and how to resolve it.
Understand Using Components with Known Vulnerabilities
All complex software has vulnerabilities. That's the nature of the beast. So your components will never be 100% safe. However, when vulnerabilities are found in components, do you know about it? Are you prepared for it?
Problems arise most often when components are used past their useful life or after vulnerabilities are found. Most components and libraries release patches for security vulnerabilities at or before the same time the vulnerability is announced. Therefore, when vulnerabilities in components are discovered and announced, updating the components as soon as possible is of utmost importance. Don't leave vulnerable software in production.
Components can come from several sources. Sometimes you buy third-party vendor products which integrate directly with your custom code. These components become a part of your code and operate at the same level of privilege. Another source is open source projects hosted on sites such as GitHub. Open source can be dangerous since not all open source libraries have been carefully vetted or audited for vulnerabilities.
Attackers use component vulnerability information to their advantage. Since the vulnerabilities are announced publicly, attackers know about the vulnerabilities the same time you do. Attackers also have techniques they can use to find out what components you're using. Once they know this information, they'll know how to attack your application if it isn't patched.
Know Why Vulnerable Components are Dangerous
If you're looking for evidence of how dangerous using components with known vulnerabilities is, look no further than the Equifax breach of 2017.
In July of 2017, Equifax, a United States credit bureau, discovered a massive data breach which leaked the personally identifiable information of over 147 million people. The scope and impact of this data breach is unprecedented. Recently, news has come out about Equifax's lax security practices.
One of those lax practices was patch management. Equifax didn't have good patch management practices, which meant their components would go quite some time without getting patched. This was the direct cause of the breach.
Equifax's website used the Apache Struts web framework. Several months before the attackers hacked into the network, a vulnerability was found in the Struts framework, Apache Struts CVE-2017-5638. However, Equifax didn't patch the vulnerability. Attackers used this vulnerability to gain access to Equifax's network. From there, they gained access to a treasure trove of personal information.
Many websites are based on web frameworks not written by the company. This is standard practice since building in all of the necessary functionality from scratch would be too large of an undertaking. However, depending strongly on a framework can open you up to vulnerabilities. Don't become the next Equifax.
How to Protect Against Vulnerable Components
There is no silver bullet to protecting against using vulnerable components. However, there are policies and controls you can use to mitigate the risk of vulnerable components being used to compromise your systems.
You need to know what components and which version of each component you're using to build your applications. Dependency management tools such as OWASP's Dependency Check help you to get a handle on what dependencies you're using. Dependency Check will also tell you if any of those components has a publicly disclosed vulnerability.
A patch management methodology is also essential. When vulnerabilities are discovered, have a system in place for the patches to be downloaded, tested, and released into production smoothly. Keeping your software patched prevents months-old vulnerabilities from being used by attackers.
Finally, have policies in place governing the use of open source and third-party components. Developers don't like to have red tape, and that is understandable. However, there has to be a vetting process for code not written by your organization. It doesn't have to be heavyweight, but is a must to prevent unknown components from being used. At the least, an inventory of components used must be kept up-to-date.
Don't Get Bitten by the Third-Party Bug
Components will have vulnerabilities. You business applications will use components, whether from a vendor or from an open source library. This doesn't mean your organization need be vulnerable to attack.
Even though attackers know what vulnerabilities exist at the same time you do, patches usually are made available at the same time as the public announcements. So, be sure to educate yourself on what your application is using. Know what is vulnerable. Keep your components patched!
Ready to discover (and defeat) some vulnerable components? Head to the arena to engage in battle: [Start Here]
Since all applications use components, most of which you haven't written, vulnerabilities within the components you use can become liabilities. Let's discuss what using components with known vulnerabilities means, how dangerous it is, and how to resolve it.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
What is the one thing that all applications have? Components, also known as dependencies or libraries. There is very little code in the world that doesn't depend on other code at some point in time. You even start with a mountain of dependencies from the time you create the application!
Since all applications use components, most of which you haven't written, vulnerabilities within the components you use can become liabilities. Let's discuss what using components with known vulnerabilities means, how dangerous it is, and how to resolve it.
Understand Using Components with Known Vulnerabilities
All complex software has vulnerabilities. That's the nature of the beast. So your components will never be 100% safe. However, when vulnerabilities are found in components, do you know about it? Are you prepared for it?
Problems arise most often when components are used past their useful life or after vulnerabilities are found. Most components and libraries release patches for security vulnerabilities at or before the same time the vulnerability is announced. Therefore, when vulnerabilities in components are discovered and announced, updating the components as soon as possible is of utmost importance. Don't leave vulnerable software in production.
Components can come from several sources. Sometimes you buy third-party vendor products which integrate directly with your custom code. These components become a part of your code and operate at the same level of privilege. Another source is open source projects hosted on sites such as GitHub. Open source can be dangerous since not all open source libraries have been carefully vetted or audited for vulnerabilities.
Attackers use component vulnerability information to their advantage. Since the vulnerabilities are announced publicly, attackers know about the vulnerabilities the same time you do. Attackers also have techniques they can use to find out what components you're using. Once they know this information, they'll know how to attack your application if it isn't patched.
Know Why Vulnerable Components are Dangerous
If you're looking for evidence of how dangerous using components with known vulnerabilities is, look no further than the Equifax breach of 2017.
In July of 2017, Equifax, a United States credit bureau, discovered a massive data breach which leaked the personally identifiable information of over 147 million people. The scope and impact of this data breach is unprecedented. Recently, news has come out about Equifax's lax security practices.
One of those lax practices was patch management. Equifax didn't have good patch management practices, which meant their components would go quite some time without getting patched. This was the direct cause of the breach.
Equifax's website used the Apache Struts web framework. Several months before the attackers hacked into the network, a vulnerability was found in the Struts framework, Apache Struts CVE-2017-5638. However, Equifax didn't patch the vulnerability. Attackers used this vulnerability to gain access to Equifax's network. From there, they gained access to a treasure trove of personal information.
Many websites are based on web frameworks not written by the company. This is standard practice since building in all of the necessary functionality from scratch would be too large of an undertaking. However, depending strongly on a framework can open you up to vulnerabilities. Don't become the next Equifax.
How to Protect Against Vulnerable Components
There is no silver bullet to protecting against using vulnerable components. However, there are policies and controls you can use to mitigate the risk of vulnerable components being used to compromise your systems.
You need to know what components and which version of each component you're using to build your applications. Dependency management tools such as OWASP's Dependency Check help you to get a handle on what dependencies you're using. Dependency Check will also tell you if any of those components has a publicly disclosed vulnerability.
A patch management methodology is also essential. When vulnerabilities are discovered, have a system in place for the patches to be downloaded, tested, and released into production smoothly. Keeping your software patched prevents months-old vulnerabilities from being used by attackers.
Finally, have policies in place governing the use of open source and third-party components. Developers don't like to have red tape, and that is understandable. However, there has to be a vetting process for code not written by your organization. It doesn't have to be heavyweight, but is a must to prevent unknown components from being used. At the least, an inventory of components used must be kept up-to-date.
Don't Get Bitten by the Third-Party Bug
Components will have vulnerabilities. You business applications will use components, whether from a vendor or from an open source library. This doesn't mean your organization need be vulnerable to attack.
Even though attackers know what vulnerabilities exist at the same time you do, patches usually are made available at the same time as the public announcements. So, be sure to educate yourself on what your application is using. Know what is vulnerable. Keep your components patched!
Ready to discover (and defeat) some vulnerable components? Head to the arena to engage in battle: [Start Here]
What is the one thing that all applications have? Components, also known as dependencies or libraries. There is very little code in the world that doesn't depend on other code at some point in time. You even start with a mountain of dependencies from the time you create the application!
Since all applications use components, most of which you haven't written, vulnerabilities within the components you use can become liabilities. Let's discuss what using components with known vulnerabilities means, how dangerous it is, and how to resolve it.
Understand Using Components with Known Vulnerabilities
All complex software has vulnerabilities. That's the nature of the beast. So your components will never be 100% safe. However, when vulnerabilities are found in components, do you know about it? Are you prepared for it?
Problems arise most often when components are used past their useful life or after vulnerabilities are found. Most components and libraries release patches for security vulnerabilities at or before the same time the vulnerability is announced. Therefore, when vulnerabilities in components are discovered and announced, updating the components as soon as possible is of utmost importance. Don't leave vulnerable software in production.
Components can come from several sources. Sometimes you buy third-party vendor products which integrate directly with your custom code. These components become a part of your code and operate at the same level of privilege. Another source is open source projects hosted on sites such as GitHub. Open source can be dangerous since not all open source libraries have been carefully vetted or audited for vulnerabilities.
Attackers use component vulnerability information to their advantage. Since the vulnerabilities are announced publicly, attackers know about the vulnerabilities the same time you do. Attackers also have techniques they can use to find out what components you're using. Once they know this information, they'll know how to attack your application if it isn't patched.
Know Why Vulnerable Components are Dangerous
If you're looking for evidence of how dangerous using components with known vulnerabilities is, look no further than the Equifax breach of 2017.
In July of 2017, Equifax, a United States credit bureau, discovered a massive data breach which leaked the personally identifiable information of over 147 million people. The scope and impact of this data breach is unprecedented. Recently, news has come out about Equifax's lax security practices.
One of those lax practices was patch management. Equifax didn't have good patch management practices, which meant their components would go quite some time without getting patched. This was the direct cause of the breach.
Equifax's website used the Apache Struts web framework. Several months before the attackers hacked into the network, a vulnerability was found in the Struts framework, Apache Struts CVE-2017-5638. However, Equifax didn't patch the vulnerability. Attackers used this vulnerability to gain access to Equifax's network. From there, they gained access to a treasure trove of personal information.
Many websites are based on web frameworks not written by the company. This is standard practice since building in all of the necessary functionality from scratch would be too large of an undertaking. However, depending strongly on a framework can open you up to vulnerabilities. Don't become the next Equifax.
How to Protect Against Vulnerable Components
There is no silver bullet to protecting against using vulnerable components. However, there are policies and controls you can use to mitigate the risk of vulnerable components being used to compromise your systems.
You need to know what components and which version of each component you're using to build your applications. Dependency management tools such as OWASP's Dependency Check help you to get a handle on what dependencies you're using. Dependency Check will also tell you if any of those components has a publicly disclosed vulnerability.
A patch management methodology is also essential. When vulnerabilities are discovered, have a system in place for the patches to be downloaded, tested, and released into production smoothly. Keeping your software patched prevents months-old vulnerabilities from being used by attackers.
Finally, have policies in place governing the use of open source and third-party components. Developers don't like to have red tape, and that is understandable. However, there has to be a vetting process for code not written by your organization. It doesn't have to be heavyweight, but is a must to prevent unknown components from being used. At the least, an inventory of components used must be kept up-to-date.
Don't Get Bitten by the Third-Party Bug
Components will have vulnerabilities. You business applications will use components, whether from a vendor or from an open source library. This doesn't mean your organization need be vulnerable to attack.
Even though attackers know what vulnerabilities exist at the same time you do, patches usually are made available at the same time as the public announcements. So, be sure to educate yourself on what your application is using. Know what is vulnerable. Keep your components patched!
Ready to discover (and defeat) some vulnerable components? Head to the arena to engage in battle: [Start Here]
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
What is the one thing that all applications have? Components, also known as dependencies or libraries. There is very little code in the world that doesn't depend on other code at some point in time. You even start with a mountain of dependencies from the time you create the application!
Since all applications use components, most of which you haven't written, vulnerabilities within the components you use can become liabilities. Let's discuss what using components with known vulnerabilities means, how dangerous it is, and how to resolve it.
Understand Using Components with Known Vulnerabilities
All complex software has vulnerabilities. That's the nature of the beast. So your components will never be 100% safe. However, when vulnerabilities are found in components, do you know about it? Are you prepared for it?
Problems arise most often when components are used past their useful life or after vulnerabilities are found. Most components and libraries release patches for security vulnerabilities at or before the same time the vulnerability is announced. Therefore, when vulnerabilities in components are discovered and announced, updating the components as soon as possible is of utmost importance. Don't leave vulnerable software in production.
Components can come from several sources. Sometimes you buy third-party vendor products which integrate directly with your custom code. These components become a part of your code and operate at the same level of privilege. Another source is open source projects hosted on sites such as GitHub. Open source can be dangerous since not all open source libraries have been carefully vetted or audited for vulnerabilities.
Attackers use component vulnerability information to their advantage. Since the vulnerabilities are announced publicly, attackers know about the vulnerabilities the same time you do. Attackers also have techniques they can use to find out what components you're using. Once they know this information, they'll know how to attack your application if it isn't patched.
Know Why Vulnerable Components are Dangerous
If you're looking for evidence of how dangerous using components with known vulnerabilities is, look no further than the Equifax breach of 2017.
In July of 2017, Equifax, a United States credit bureau, discovered a massive data breach which leaked the personally identifiable information of over 147 million people. The scope and impact of this data breach is unprecedented. Recently, news has come out about Equifax's lax security practices.
One of those lax practices was patch management. Equifax didn't have good patch management practices, which meant their components would go quite some time without getting patched. This was the direct cause of the breach.
Equifax's website used the Apache Struts web framework. Several months before the attackers hacked into the network, a vulnerability was found in the Struts framework, Apache Struts CVE-2017-5638. However, Equifax didn't patch the vulnerability. Attackers used this vulnerability to gain access to Equifax's network. From there, they gained access to a treasure trove of personal information.
Many websites are based on web frameworks not written by the company. This is standard practice since building in all of the necessary functionality from scratch would be too large of an undertaking. However, depending strongly on a framework can open you up to vulnerabilities. Don't become the next Equifax.
How to Protect Against Vulnerable Components
There is no silver bullet to protecting against using vulnerable components. However, there are policies and controls you can use to mitigate the risk of vulnerable components being used to compromise your systems.
You need to know what components and which version of each component you're using to build your applications. Dependency management tools such as OWASP's Dependency Check help you to get a handle on what dependencies you're using. Dependency Check will also tell you if any of those components has a publicly disclosed vulnerability.
A patch management methodology is also essential. When vulnerabilities are discovered, have a system in place for the patches to be downloaded, tested, and released into production smoothly. Keeping your software patched prevents months-old vulnerabilities from being used by attackers.
Finally, have policies in place governing the use of open source and third-party components. Developers don't like to have red tape, and that is understandable. However, there has to be a vetting process for code not written by your organization. It doesn't have to be heavyweight, but is a must to prevent unknown components from being used. At the least, an inventory of components used must be kept up-to-date.
Don't Get Bitten by the Third-Party Bug
Components will have vulnerabilities. You business applications will use components, whether from a vendor or from an open source library. This doesn't mean your organization need be vulnerable to attack.
Even though attackers know what vulnerabilities exist at the same time you do, patches usually are made available at the same time as the public announcements. So, be sure to educate yourself on what your application is using. Know what is vulnerable. Keep your components patched!
Ready to discover (and defeat) some vulnerable components? Head to the arena to engage in battle: [Start Here]
Table of contents
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Turn Awareness Into Action This Cyber Awareness Month
This October, turn awareness into action. Make Cyber Awareness Month memorable for your developers with a high-impact, high-participation experience—led by Secure Code Warrior's Professional Services team.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
