What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2021-09-23 08:55:21 | Application Security Testing Evolution and How a Software Bill of Materials Can Help (lien direct) | Early in my career, I developed web applications. At the time there were practically no frameworks or libraries to help. I was coding with Java using raw servlets and JSPs – very primitive by today's standards. There was no OWASP Top 10 and writing secure code was not something we paid much attention to. I specifically remember coding an open redirect years ago. I didn't know it was a vulnerability at the time. In my mind, it was a great feature for my Java servlet to recognize a special query string parameter that, if present, would trigger a redirection to the given URL! Interestingly, a dynamic scan or penetration test of the application would not have found my vulnerability. The name of the parameter was undocumented and not easy to guess. On the other hand, static application security testing (SAST) or a manual code review would have found it. My first stint at Veracode was in 2012, after six years working as an application security consultant. It was exciting to join an up-and-coming company on the cutting-edge of AppSec testing. Since then, open source software has grown enormously and proliferated in all aspects of application development. Building apps today is faster because of how easy it is to integrate these components into our own projects. Package managers and open source registries like Maven repository, NPM registry, PyPI, and RubyGems.org provide a way for developers to quickly access and leverage a rich plethora of ready-to-use libraries and frameworks. The downside with this model of building applications is that vulnerabilities present in open source components are inherited by our software as well. This has resulted in many data breaches over the years (Equifax via Apache Struts comes to mind). One of the reasons I recently re-joined Veracode is to have the opportunity work with a premier Software Composition Analysis (SCA) tool. SCA is complementary to SAST. While SAST checks 1st-party code for security flaws, SCA looks at 3rd-party code like open source libraries. In terms of the OWASP Top 10, this falls under OWASP #9 – Using Components with Known Vulnerabilities. If your application is using a vulnerable component, it's not necessarily your fault. The vulnerable component may be present because a library that your code is using directly has a dependency on another library. This is called a transitive dependency. Transitive dependencies are pulled in automatically by build systems, aka package managers. Data from our State of Software Security: Open Source Edition report shows that 71 percent of applications have a vulnerability in an open source library on initial scan, and that nearly half of those (47 percent) are transitive. Now let's talk about a software bill of materials (SBOM). An SBOM lists the individual components that are included in a piece of software. This can help with identifying vulnerabilities or license risks that may affect your organization. The concept of an SBOM is not new, but it's garnered much more interest lately due to the recent U.S. Cybersecurity Executive Order. One of its requirements is having an SBOM for all critical software sold to the federal government. There are different SBOM specifications in the marketplace today. I will focus on CycloneDX, which was recently accepted as a flagship OWASP project. CycloneDX is a security-focused SBOM specification and capable of describing the following types of components: Application Container Device File Firmware Framework Library Operating System Service CycloneDX's supported data formats are XML, JSON, and Protobuf. Here's an example of a CycloneDX SBOM in JSON format: Right away we can see that the software represented by this SBOM includes one library –Apache's Commons Collections ver | Vulnerability | Equifax | |
|
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-11-10 09:10:27 | In the Financial Services Industry, 74% of Apps Have Security Flaws (lien direct) |  Over the past year, the financial services industry has been challenged with pivoting its operations to a fully digital model, putting the security of its software center stage. Despite the unanticipated pivot, our recent State of Software Security v11 (SOSS) report found that the financial services industry has the smallest proportion of applications with security flaws compared to other sectors, along with the second-lowest prevalence of severe security flaws, and the best security flaw fix rate.
But despite the impressive fix rate, the financial services industry is falling behind when it comes to the time to make those fixes. This is a troubling finding because speed matters in application security. The time it takes for attackers to come up with exploits for newly discovered vulnerabilities is measured in days, sometimes even hours. Letting known vulnerabilities linger unfixed dramatically increases your risk. For instance, it was merely days between disclosure and exploitation of the vulnerability in the Apache Struts framework that led to theﾂ?Equifax breach.
By looking at the data, the reason for the delay in remediation becomes more clear. In the financial services sector, applications tend to be older than those in other industry sectors and the organizations are fairly large. Combined with these challenging factors, developers and security professionals in this industry aren???t regularly employing best practices consistent with DevSecOps and known to improve fix rates, such as scanning for security both frequently and regularly and using more than one testing type.
What does this mean for the financial services industry? The data suggests that for many financial services firms, developers face a challenging environment, with the adoption of additional DevSecOps practices showing the most opportunity for improvement in addressing security flaws.
And while talking about flaws, it???s worth noting that the most common security flaws in the financial services industry are information leakage, code quality, and CRLF injection. Injection flaws are especially important to keep an eye on since they???re the top web application security risk according to OWASP Top 10. On a positive note, the industry has lower than average cryptography, input validation, Cross-Site Scripting, and credentials management flaws.
For more information on software security trends in the financial services industry, check out The State of Software Security Industry Snapshot. |
Vulnerability | 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: 5 articles.
We have: 5 articles.
To see everything:
Our RSS (filtrered)
