What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2021-02-24 13:30:31 | Dangers of Only Scanning First-Party Code (lien direct) |  When it comes to securing your applications, it???s not unusual to only consider the risks from your first-party code. But if you???re solely considering your own code, then your attack surface is likely bigger than you think.
Our recent State of Software Security report found that 97 percent of the typical Java application is made up of open source libraries. That means your attack surface is exponentially larger than just the code written in-house. Yet a study conducted by Enterprise Strategy Group (ESG) established that less than half of organizations have invested in security controls to scan for open source vulnerabilities.
If the majority of applications are made up of open source libraries, why are most organizations only scanning their first-party code? Because most organizations assume that third-party code was already scanned for vulnerabilities by the library developer. But you can???t base the safety of your applications on assumptions. Our State of Software Security: Open Source Edition report revealed that approximately 42 percent of the third-party code pulled directly by an application developer has a flaw on first scan. And even if the third-party code appears to be free of flaws, more than 47 percent of third-party code has a transitive flaw that???s pulled indirectly from another library in use.
Over the years, several organizations have learned the hard way just how dangerous it is to only scan first-party code.
In 2014, the notorious open source vulnerability ??? Heartbleed ??? occurred. Heartbleed was the result of a flaw in OpenSSL, a third-party library that implemented the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. The vulnerability enabled cyberattackers to access over 4.5 million healthcare records from Community Health Systems Inc.
In 2015, there was a critical vulnerability in Glibc, a GNU C library. The open source security vulnerability nicknamed ???Ghost,??? affected all Linux servers and web frameworks such as Python, PHP, Ruby on Rails as well as API web services that use the Glibc library. The vulnerability made it possible for hackers to compromise applications with a man-in-the-middle attack.
In 2017, Equifax suffered a massive data breach from Apache Struts which compromised the data ??? including social security numbers ??? of more than 143 million Americans. Following the breach, Equifax's stock fell over 13 percent.
On the good news front: Close to 74 percent of open source flaws can be fixed with an update like a revision or patch. Even high-priority open source flaws don???t require extensive refactoring of code ??? close to 91 percent can be fixed with an update. Equifax had to pay up to $425 million to help people affected by the data breach that the court deemed ???entirely preventable.??? In fact, it was discovered that the breach could have been avoided with a simple patch to its open source library, Apache Struts.
Don???t become a victim to the monsters lurking in your third-party libraries. Download our whitepaper Accelerating Software Development with Secure Open Source So |
Data Breach Vulnerability | Equifax Equifax | |
|
2021-01-05 13:25:00 | Nature vs. Nurture Tip 3: Employ SCA With SAST (lien direct) |  For this year???s State of Software Security v11 (SOSS) report, we examined how both the ???nature??? of applications and how we ???nurture??? them contribute to the time it takes to close out a security flaw. We found that the ???nature??? of applications ??? like size or age ??? can have a negative effect on how long it takes to remediate a security flaw. But, taking steps to ???nurture??? the security of applications ??? like using multiple application security (AppSec) testing types ??? can have a positive effect on how long it takes to remediate security flaws.
In our first blog, Nature vs. Nurture Tip 1: Use DAST With SAST, we explored how organizations that combine DAST with SAST address 50 percent of their open security findings almost 25 days faster than organizations that only use SAST. In our second blog, Nature vs. Nurture Tip 2: Scan Frequently and Consistently, we addressed the benefits of frequent and consistent scanning by highlighting the SOSS finding that organization that scan their applications at least daily reduced time to remediation by more than a third, closing 50 percent of security flaws in 2 months.
For our third tip, we will explore the importance of software composition analysis (SCA) and how ??? when used in conjunction with static application security testing (SAST) ??? it can shorten the time it takes to address security flaws.
What is SCA and why is it important?
SCA inspects open source code for vulnerabilities. Some assume that open source code is more secure than first-party code because there are ???more eyes on it,??? but that is often not the case. In fact, according to our SOSS report, almost one-third of applications have more security findings in their third-party libraries than in primary code. Given that a typical Java application is 97 percent third-party code, this is a concerning statistic.
Since SCA is the only AppSec testing type that can identify vulnerabilities in open source code, if you don???t employ SCA, you could find yourself victim of a costly breach. In fact, in 2017, Equifax suffered a massive data breach from Apache Struts that compromised the data ??? including Social Security numbers ??? of more than 143 million Americans. Following the breach, Equifax's stock fell over 13 percent.
How can SCA with SAST shorten time to remediation?
If you are only using static analysis to assess the security of your code, your attack surface is likely bigger than you think. You need to consider third-party code as part of your attack surface, which is only uncovered by using SCA.
By incorporating software composition analysis into your security testing mix, you can find and address more flaws. According to SOSS, organizations that employ ???good??? scanning practices (like SCA with SAST), tend to be more mature and further along in their AppSec journey. And organizations with mature AppSec programs tend to remediate flaws faster. For example, employing SCA with SAST cuts ti |
Data Breach | Equifax | |
|
2020-10-01 14:10:28 | 96% of Organizations Use Open Source Libraries but Less Than 50% Manage Their Library Security Flaws (lien direct) |  Most modern codebases are dependent on open source libraries. In fact, a recent research report sponsored by Veracode and conducted by Enterprise Strategy Group (ESG) found that more than 96 percent of organizations use open source libraries in their codebase. But ??? shockingly ??? less than half of these organizations have invested in specific security controls to scan for open source vulnerabilities.
Why is it important to scan open source libraries?
For our State of Software Security: Open Source Edition report, we analyzed the security of open source libraries in 85,000 applications and found that 71 percent have a flaw. The most common open source flaws identified include Cross-Site Scripting, insecure deserialization, and broken access control. By not scanning open source libraries, these flaws remain vulnerable to a cyberattack. ﾂ?ﾂ?ﾂ?
Equifax made headlines by not scanning its open source libraries. In 2017, Equifax suffered a massive data breach from Apache Struts which compromised the data ??? including social security numbers ??? of more than 143 million Americans. Following the breach, Equifax's stock fell over 13 percent. The unfortunate reality is that if Equifax performed AppSec scans on its open source libraries and patched the vulnerability, the breach could have been avoided. ﾂ?
Why aren???t more organizations scanning open source libraries?
If 96 percent of organizations use open source libraries and 71 percent of applications have a third-party vulnerability, why is it that less than 50 percent of organizations scan their open source libraries? The main reason is that when application developers add third-party libraries to their codebase, they expect that library developers have scanned the code for vulnerabilities. Unfortunately, you can???t rely on library developers to keep your application safe. Approximately 42 percent of the third-party code pulled directly by an application developer has a flaw on first scan. And even if the third-party code appears to be free of flaws, more than 47 percent of third-party code has a transitive flaw that???s pulled indirectly from another library in use.
What are your options for managing library security flaws?
First off, it???s important to note that most flaws in open source libraries are easy to fix. Close to 74 percent of the flaws can be fixed with an update like a revision or patch. Even high priority flaws are easy to fix ??? close to 91 percent can be fixed with an update.
So, when it comes to managing your library security flaws, the concentration should not just be, ???How |
Data Breach Tool Vulnerability | Equifax |
1
We have: 3 articles.
We have: 3 articles.
To see everything:
Our RSS (filtrered)
