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
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
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.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
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.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
