What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2021-06-29 11:30:29 | Speed or Security? Don\'t Compromise (lien direct) | “Speed is the new currency of business.” Chairman and CEO of Salesforce Marc R. Benioff's words are especially potent today as many organizations small and large look for ways to speed up production during their shifts to digital. In software development, speed is a critical factor. Everything from shifting priorities to manual processes and siloed teams can seriously impede deployment schedules. One of the biggest obstacles, however, is a lack of security throughout every step of the production process to ensure that coding mistakes and flaws are found and fixed before they turn into project-derailing problems. A lack of an efficient and flexible AppSec program becomes an issue when you look at the data: Cyberattacks occur every 39 seconds. 60 percent of developers are releasing code 2x faster than before. 76 percent of applications have least at least one security flaw on first scan. 85 percent of orgs admit to releasing vulnerable code to production because of time restraints. A mere 15 percent of orgs say that all of their development teams participate in formal security training. But there's good news, too. We know from our annual State of Software Security report that frequent scanning with the right tools in the right parts of your software development lifecycle can help your team close security findings much faster. For example, scanning via API alone cuts remediation time for 50 percent of flaws by six days, slamming that window of opportunity shut for cyberattackers. The Veracode Static Analysis family helps you do just that. It plugs into critical parts of your software development lifecycle (SDLC), providing automated feedback right in your IDE and pipeline so that your developers can improve the quality of their code while they work. You can also run a full policy scan before deployment to understand what your developers need to focus on and to prove compliance. Together, these scans throughout My Code, Our Code, and Production Code boost quality and security to reduce the risk of an expensive and time-consuming breach down the road. Automation and developer education In addition to having the right scans in the right places, there are supporting steps you can take to ensure the quality of your code without sacrificing speed. Automation through integrations is an important piece of the puzzle because it speeds everything up and boosts efficiency. The automated feedback from Veracode Static Analysis means your team of developers has clear insight into existing flaws so they can begin prioritization to eliminate the biggest risks first. Automation also sets the standard for consistency which, as you go, improves speed. Developer education also helps close gaps in information and communication with security counterparts so that they can work towards a common goal. It goes both ways – if the security leaders at your organization can walk the walk and talk the talk of the developer, everyone will have an easier time communicating goals and solving security problems. One way to close those gaps is through hands-on developer education with a tool like Veracode Security Labs. The platform utilizes real applications in contained environments that developers can hack or patch in real-time so that they learn to think like an attacker and stay one step ahead. Like Static Analysis, Security Labs helps meet compliance needs too, with customized education in the languages your developers use most. The prioritization conundrum Security debt can feel like a horror movie villain as it lingers in the background. But it isn't always teeming with high-risk flaws that should be tackled first, and so it's important to carefully consider how to approach prioritization. A recent analyst report, Building an Enterprise DevSecOps Program, found that everything can feel like a priority: “During our research many security pros told us that all vulnerabilities started looking like high priorities, and it was incredibly difficult to differentiate a vulnerability with impact on the organization from one which | Hack Tool Vulnerability Guideline | ||
|
2021-06-25 08:57:23 | Key Takeaways From State of Software Security v11: Open Source Edition (lien direct) | We recently published a special open source edition of our annual State of Software Security (SOSS) report. The State of Software Security v11: Open Source Edition analyzed the data collected from 13 million scans of more than 86,000 repositories, containing more than 301,000 unique libraries. We also added some color and context to the data this year by surveying our customer base and adding the data from 1,744 responses to the report. In last year's open source report, we looked at a snapshot of library usage in applications. This year, we looked beyond the point-in-time snapshot to examine the dynamics of library development and how developers react to library changes, including the discovery of flaws. Here are some of the key takeaways for security professionals: The most popular libraries from last year are not the most popular libraries this year. And the most secure libraries from last year are not the most secure libraries this year. Some languages saw little to no change in library popularity from 2019 to 2020, like Java. But other languages underwent significant changes in their library landscapes. For example, Swift's top two libraries from 2019, Crashlytics and Fabric, did not even break the top 20 in 2020. This is due to the fact that Google (the parent company behind Firebase) acquired both companies and integrated the functionality into Firebase, leading to the meteoric rise in two Firebase libraries. The most secure libraries have also changed. The Twisted library in Python was very secure last year, but this year it's far from secure. This is likely attributable to the expanding capabilities of the built-in functionality in Python, with the built-in library asyncio receiving significant updates in 2016 and late 2018, and perhaps more importantly has only seen one CVE associated with it (CVE-2021-21330), in contrast to Twisted's seven. Security takeaway: What's popular and what's secure in your library landscape can change dramatically within the span of a year. Keeping an inventory of what's in your application is important. 79 percent of developers never update third-party libraries after including them in a codebase. Once developers pick a library or version, they tend to stick with it. 65 percent of libraries appear in the first scan of the repository and are never updated. An additional 14 percent of libraries are added at some point during development and are never updated to a new version. The languages that are most likely to be “set and forgotten about” include Ruby, JavaScript, and Java. Security takeaway: Most third-party libraries aren't updated once added to a codebase. This is especially alarming considering that, in last year's open source report, we found that almost one-third of applications have more security findings in third-party libraries than in the native codebase. And even if a library is secure when you add it to your codebase, we saw above that the security of libraries changes frequently. Open source libraries are not a set-it-and-forget-it activity, but rather one that requires maintenance. When alerted to vulnerabilities, developers act quickly. But that maintenance is not necessarily overly taxing. We found that once alerted to a vulnerability in a library, developers fix nearly 17 percent of vulnerable libraries within an hour and 25 percent within seven days. Security takeaway: With the right information and prioritization, security vulnerabilities in open source libraries can be addressed quickly. Without knowledge of how vulnerabilities relate to their applications, developers struggle to address them. Vulnerabilities can be addressed quickly, but if developers don't have the right contextual information, such as how a vulnerability impacts their application, it can take more than seven months to fix 50 percent of flaws. Those that have the information they need fix 50 percent of flaws in just three weeks. Security takeaway: 92 percent of library flaws can be fixed with an update, and 69 percent of updates are a minor version change or less. But lac | Vulnerability Guideline | ||
|
2021-06-01 16:45:52 | Veracode Named a Leader in 2021 Gartner Magic Quadrant for Application Security Testing (lien direct) |  Veracode has been named a Leader in the 2021 Gartner Magic Quadrant for Application Security Testing (AST) for the eighth consecutive year. Gartner evaluates vendors based on their completeness of vision and ability to execute in the application security testing (AST) market. This recognition comes just months after we were named Gartner Peer Insights Customers??? Choice for AST, proving, in our opinion, the strength of our AST offerings according to both experts and users.
 ???
In addition, we received the highest score for the Enterprise and Public-Facing Web Applications Use Cases in the 2021 Gartner Critical Capabilities for Application Security Testing report.
We???re thrilled to be recognized as a Leader in the Magic Quadrant once again. Committed to helping organizations in every industry code with confidence in our increasingly digital world, we spent the last year striving to enable developers to code securely, and security teams to easily measure and report on the security posture of their organizations.
Veracode has increased its focus and investment in DevSecOps and developer enablement and education, with expanded integrations into developer ecosystems, including AWS CodeStar, secure coding best practices, and expert consultations. The platform offers support for GitHub Actions and GitHub Security Console and issues and pipelines, as well as a pipeline approach that optimizes scan times throughout the software development process. Through the introduction of Veracode Security Labs in early 2020, the company also offers hands-on, interactive security training to developers that aims to enable developers to code securely. As the director of engineering at OneLogin recently remarked, ???Veracode [Security Labs] has significantly reduced the number of defects introduced during the development process and has ingrained security best practices as a primary pillar of creating production-quality code.???
A true enterprise offering includes a comprehensive approach to application security. Veracode credits its high scores for Enterprise and Public-Facing Web Applications in the Critical Capabilities report to a single platform that scans for vulnerabilities in both first-party and open source code with multiple testing types, quick time to deployment without absorbing infrastructure costs, constant updates, and machine learning that facilitates remediation. Unique in the market, Veracode SCA doesn???t rely solely on the National Vulnerability Database (NVD) but also uses machine learning, data mining, and natural language processing to identify potential vulnerabilities inﾂ?open sourceﾂ?libraries from commit messages and bug reports.
Software security will be increasingly critical as the world becomes even more connected and digital, and as high-profile cyberattacks prompt more stringent regulations. In fact, nearly a quarter of the Biden administration???s newly launched executive order on cybersecurity is focused on securing the software supply chain, and the 2021 Gartner Magic Quadrant authors highlight that ???Gartner estimates end-user spending in the AST market reached $2.2 billion worldwide in 2020. We have also increased our growth rate proj |
Vulnerability Guideline | ||
|
2021-05-18 14:54:52 | A Closer Look at the Software Supply Chain Requirements in the Cybersecurity Executive Order (lien direct) |  Software security is a big focus of the Biden administration???s recentﾂ?executive orderﾂ?on cybersecurity. In fact, an entire section, or 25 percent, of the order is dedicated to software security requirements. In the wake of the SolarWinds cyberattack, the security of the software supply chain is clearly top of mind at the White House, and has prompted these unprecedented and detailed security requirements for any software vendor looking to do business with the federal government. The order states:
The security of software used by the Federal Government is vital toﾂ?the Federal Government???s ability to perform its critical functions.ﾂ? The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.ﾂ? There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended.ﾂ? The security and integrity of ???critical software??? ??? software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) ??? is a particular concern.ﾂ? Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.
How will the requirements be developed, and what do they cover?
The order mandates that NIST will identify existing or develop new standards for software security that ???shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.??? NIST has 180 days to publish the preliminary guidelines, so we expect to see them before the end of the year.
Once the preliminary guidelines are published, NIST will then, within 60 days, issue guidance on best practices for securing the software supply chain (most likely early 2022). This guidance must include standards for:
Secure software development environments
Generating proof of adherence to the standards
Employing automated tools to ???ensure the integrity of code???
Employing automated tools to check for vulnerabilities and remediate them
Generating proof of the results of the automated tools??? findings
Maintaining data on the origins of all software code
Providing a software bill of materials
Participating in a vulnerability disclosure program
Attesting to conformity with secure software development practices
Ensuring the integrity of open source software in use
The order covers both new software purchases, and a review of existing legacy software.
There will also be guidance coming on what constitutes a software bill of materials and what should be considered ???critical software.???
Finally, the order requires the development of a pilot program that will examine a security labeling and rating system for consumer software products, including IoT devices.
What???s notable?
SBOM requirement:ﾂ?The requirement to provide a software bill of materials for each software product is a notable acknowledgement of the reality of modern software ??? very little of it is created from scratch, in-house. Just as requirements surrounding nutrition and ingredients labeling evolved over time as food products became more complicated and aware |
Vulnerability Threat | ||
|
2021-05-13 07:45:23 | New Cybersecurity Executive Order: What You Need to Know (lien direct) |  Last night, the Biden administration released an executive order on cybersecurity that includes new security requirements for software vendors selling software to the U.S. government. These requirements include security testing in the development process and a bill of materials for the open source libraries in use, so known vulnerabilities are disclosed and able to be tracked in the future. Without following these standards, companies will not be able to sell software to the federal government. There are also indications that these practices will make their way into the private sector as much of the software sold to the government is also sold to enterprises. That said, we???re working on a series of blog posts and other content that will break this order down for you and track the development of the standards as they are developed by NIST over the course of the next 12 months. We???ve been advising and collaborating with the government (starting with testifying before Congress 23 years ago), and other standards bodies for years on this very topic, in addition to working with large enterprises in highly regulated industries like financial services and healthcare to help them comply with similar standards. We???ll be using our experience and expertise to share our best practices, lessons learned, and data gathered from helping over 2,500 customers secure their software.
What???s in the order?
In the wake of recent cyberattacks on government agencies through software from SolarWinds and Microsoft, this order aims to better protect government systems from a vulnerable software supply chain. Noting that ???the trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is, and to the consequences we will incur if that trust is misplaced,??? the order includes requirements for:
The security of software eligible for purchase by the federal government
Communication and collaboration on cybersecurity between the private sector and government agencies, and between government agencies
Modernizing the federal government???s cybersecurity
In terms of improving communication and collaboration, initiatives in the order include the establishme |
Vulnerability Threat | ||
|
2021-04-23 12:58:34 | Are You Targeting These Risky Red Zone Vulnerabilities? (lien direct) |  Modern software development is full of security risk. Factors like lingering security debt, insecure open source libraries, and irregular scanning cadences can all impact how many flaws dawdle in your code, leading to higher rates of dangerous bugs in susceptible and popular languages. For example, we know from State of Software Security v11 that PHP has a high rate (nearly 75 percent) of cross-site scripting flaws on initial scan, which is also the most common type of open source code vulnerability across nearly every language. It???s a dangerous one.
CRLF injection ??? which is commonly seen in Java and JavaScript ??? can lead to maliciously manipulated web applications if a threat actor is able to inject a CRLF sequence into an HTTP stream. CRLF injection is dangerous and appears in a sizeable 65 percent of applications with a flaw on initial scan, posing a decent risk to apps written in Java and JavaScript if left unchecked.
 ???
But not all flaws are so high-risk for common languages; Information Leakage, for example, is most often seen in .NET, PHP, and Java, typically stemming from a lack of secure code training. To stay one step ahead of even the low-risk (and high-risk) flaws, developers need to be armed with the right knowledge and tools so that they can produce more secure code to reduce the chance of a breach ??? whether low risk or in the danger zone.
 ???
Understanding how flaws impact programming languages across the board is crucial to preventing them. Take note of which languages tend to carry the most high-risk flaws first; whether or not yours in the mix, it???s a good idea to brush up on secure coding best practices and try your hand at hacking and patching real applications with Veracode Security Labs.
You can???t fake it when it comes to security: hands-on-keyboard education is critical to jumping these (and other) hurdles as you create innovative applications. If you want to keep data safe and squash these risky bugs, you have to think like an attacker and avoid flaw-filled curveballs in the future.
To learn more about which vulnerabilities are in the danger zone (and how to go about preventing them), check out our infosheet here. |
Vulnerability Threat Patching Guideline | ||
|
2021-04-23 09:19:39 | Practical Steps for Fixing Flaws and Creating Fewer Vulnerabilities (lien direct) |  All security flaws should be fixed, right? In an ideal world, yes, all security flaws should be fixed as soon as they???re discovered. But for most organizations, fixing all security flaws isn???t feasible.
A practical step your organization can ??? and should ??? take is to prioritize which flaws should be fixed first. To figure out which flaws should take precedence on your remediation ???to-do??? list, consider defect severity, the criticality of the application, and how easy it would be to exploit the flaw. In other words, which flaws pose real and immediate risk?
Once you???ve determined which flaws should be fixed first ??? like OWASP Top 10 vulnerabilities ??? you can create an application security (AppSec) policy to break the build whenever a flaw falls into that category. For example, if an AppSec scan uncovers a SQL injection flaw, it will break the build so that a developer can fix the flaw prior to production.
At this time, developers have three options for fixing the flaw: remediation, mitigation, or acceptance. Remediation fixes a vulnerability using code or configuration changes or patches. Mitigation is used when the primary control is not available or not feasible to implement, so compensatory controls (such as virtual patches with a WAF) are put in place to reduce or eliminate the exploitability of the vulnerability. And lastly, acceptance is used if the vulnerability is declared low-risk and not worth remediating.
As your developers get used to the AppSec policy and are comfortable fixing OWASP Top 10 flaws, you can then add additional policies. But it???s important that you don???t add too many policies at once. (Unrealistically high expectations for flaw remediation can result in developers taking shortcuts to avoid the policies.)
Another way to ???fix??? flaws is to prevent them from existing in the first place. If you train your developers to write secure code, you can decrease the number of code errors that will need to be fixed later in the software development lifecycle (SDLC). Integrating automated security tools early into the SDLC and providing guidance for fixing security-related defects can also prevent late-stage fixes.
And, if your organization isn???t doing so already, start scanning more frequently. Scanning frequently not only ensures that you???re introducing fewer flaws into your code, but also helps improve time to flaw remediation. In fact, according to our State of Software Security v11 report, scanning frequently can reduce the time it takes to remediate 50 percent of security flaws by 22.5 days.ﾂ?
Bottom line: the best way to fix flaws fast while creating fewer vulnerabilities is to prioritize which flaws to fix first, train your developers to write secure code, integrate and automate security tools early into the SDLC, and scan frequently.
To learn more about AppSec best practices and practical first steps ??? like which AppSec testing types to deploy first or how to shift left ??? or for additional information on fixing security flaws, check out our guide, Application Security Best Practices vs |
Vulnerability | ||
|
2021-03-16 10:45:23 | Automated Security Testing for Developers (lien direct) |  Today, more than ever before, development organizations are focusing their efforts on reducing the amount of time it takes to develop and deliver software applications. While this increase in velocity provides significant benefits for the end users and the business, it does complicate the process for testing and verifying the function and security of a release.
The days of long-running, waterfall-style development cycles, wherein security was manually evaluated and bolted on at the end, are gone for good. With the move towards an agile development methodology, security testing and remediation is inherently shifting to the left. And to support this, developers must adopt tools to automate security testing for easy vulnerability identification at the earliest point possible in the development lifecycle.
Below, we discuss the why and how of implementing an effective strategy for automated security testing within the development lifecycle.
Shifting security testing to the left
Through the use of automation, security testing can be executed earlier (or left) in the development pipeline. This is advantageous for a variety of reasons. For one, the earlier vulnerabilities are discovered, the less expensive they are to fix. If a security issue was introduced into the code early in the release cycle, it???s more likely that it???ll be resolved in minutes or hours. Whereas, a vulnerability discovered at the end of the release cycle could face complexity that increases the time required to remediate.
Moreover, earlier execution of security tests ensures that vulnerabilities pose less of a threat to the delivery schedule. When security tests are automated as part of the build and integration processes, there is less uncertainty as the release approaches the later stages of the development lifecycle. This reflects well on both development personnel and the organization as a whole.
Shifting security left can also help reduce security debt, which piles up over time and can only add to serious risk if left unchecked. Instead of leaving the prioritization and remediation of bugs and vulnerabilities until the very end, shifting security left encourages collaboration between security and development to tackle this issue and determine which security debt is acceptable, and which should be remediated ASAP, reducing lingering risk.
Automated security testing for developers
So with the intent being to automate and shift security testing to the earliest possible point in the development lifecycle, let???s analyze how this is done in practice.
What are we looking for when we test? What does automated security testing involve?
Automated security testing for applications is accomplished by scanning code for vulnerabilities. Static code analysis, for instance, scans a codebase while the application is not running. The code is evaluated against a set of policies to ensure that developer implementation is in compliance with the security standards set forth by the organization. Non-compliance with any standard would indicate a vulnerability. These vulnerabilities can include anything from failure to properly protect database calls from SQL injection, to non-compliance with PCI standards for processing, storing, and transmitting credit card information. Furthermore, automated security testing can be leveraged to validate the security of third-party libraries being used by the system.
Organizations that wish to shorten their development cycles and enable continuous delivery should uti |
Tool Vulnerability Threat | ★★★ | |
|
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-02-10 12:58:21 | 75% of Apps in the Healthcare Industry Have a Security Vulnerability (lien direct) |  In light of the current pandemic, our healthcare industry has been challenged like never before. Healthcare workers heroically stepped up to the plate, caring for those in need, while the industry itself digitally transformed to keep up with the influx of patient data and virtual wellness appointments.
The increase of digital activity has brought about new security threats with cyberattackers targeting patient data. In fact, according to a recent article in Modern Healthcare, ???the FBI and two federal agencies warned cybercriminals were ramping up efforts to steal data and disrupt services across the healthcare sector.??? In September, a ransomware attack affected over 250 U.S. hospitals and clinics, preventing the use of critical emergency room equipment that relies on ethernet cabling.
The increase in cyberattacks in the healthcare industry is important to note because, according to our recent State of Software Security (SOSS) report, 75 percent of applications in the healthcare industry have a security vulnerability and 26 percent have high-severity security vulnerabilities.
Our SOSS data shows that the healthcare industry has a fix rate of 70 percent, a lower rate than average when compared to other industries. But, on a positive note, the industry ranks second in the median time it takes to remediate flaws. This suggests that healthcare organizations move quickly to address security flaws in order to keep security debt from getting too out of hand.
The SOSS report also examines how ???nature??? and ???nurture??? influence applications. We found that the ???nature??? of applications ??? like organization or application size, application age, or flaw density ??? can affect how long it takes to remediate a security flaw. But, ???nurturing??? applications ??? like using multiple application security (AppSec) testing types, scanning frequently and steadily, and utilizing APIs to scan for security ??? can also influence how long it takes to remediate security flaws.
In terms of nature, healthcare organizations may be a little on the large side, but applications are fairly new and reasonably sized. The applications also have a low flaw density, which means flaws are present only in certain parts of the application.
In terms of nature, the healthcare industry is average compared to others for API usage and excels at scanning on a steady cadence and using dynamic application security testing. To improve its fix rate and median time to remediation, the healthcare industry needs to follow more DevSecOps best practices by improving its scan frequency and implementing software composition analysis. As Chris Eng, Chief Research Officer at Veracode notes, ???the healthcare industry scans on steady cadence, like clockwork, but they aren???t scanning frequently enough. By increasing the frequency of scans, we could start to see improved fix rates.???
The healthcare industry should be proud of its developers for doing a good job handing issues related to CRLF injection and cryptography. Injection flaws are considered by OWASP Top 10 to be the number one most critical security risk to web applic |
Ransomware Vulnerability | ||
|
2021-02-01 12:07:49 | Customer Q and A: Advantasure Developers Talk AppSec (lien direct) |  Before selecting Veracode, Advantasure, a leader in the healthcare technology industry, was on the hunt for an AppSec program that would not only protect them against cyberattacks, but also prove compliance with laws and regulations in several states. After integrating Veracode???s solutions and methodologies into their software development process, Advantasure reduced its time to remediation for high-severity flaws, sped up deployment, alleviated training burdens with Veracode eLearning, and enabled compliance with state and federal regulations.
To dig into some of these successes, we recently sat down with members of the Advantasure development team to discuss how our AppSec solutions and methodologies have helped them improve their development processes, reduce risk, and foster a more collaborative environment. Those team members included Sue McTaggart, Senior Application Security Architect; Bindiya Pradhan, DevOps/Release Engineer II; Vladimir Shuklin, Senior Software Engineer; Yuri Shcherbakov, Senior Software Developer/Software Engineer III; and Clay Corrello, Lead Software Engineer. Read on to read about the current state of AppSec from developers who face it every day.
What does your role look like at Advantasure?
Sue: I???m a Senior Application Security Architect at Advantasure and the product owner of Veracode. We use Static Analysis (including IDE Scan), Dynamic Analysis, Software Composition Analysis, and eLearning as well in our day-to-day work. When it comes to the several hundred developers I work with, it???s important for me to empower them through training while coaching them to be successful. I???m passionate every day about making sure my program is successful while empowering the ???doer.???
Bindiya: I???m a DevOps/Release Engineer II working as a Lead Configuration Engineer and Admin for the Veracode platform at Advantasure. I???ve been with this company for 12 years now, and I have been in software development and engineering for 20 years. I???ve had all sorts of experience in this company from design to development, and I worked on the initial development of all the software. I was first involved with Client Implementation before I moved to Client Operations, then I shifted to a DevOps team for all of our automations and CI/CD pipeline implementation.
I???m currently leading the Veracode configuration where I???m integrating Veracode with our CI/CD pipeline from development to integration of the scans. I can see how important security is. It used to be that developers thought security wasn???t their problem and the security team would say the developers are coding so it should fall on them, but now with this shift to DevSecOps I can see both sides, so it???s a great opportunity for me.ﾂ?
???It used to be that developers thought security wasn???t their problem and the security team would say the developers are coding so it should fall on them, but now with this shift to DevSecOps I can see both sides, so it???s a great opportunity for me.???
Clay: I???ve been with Advantasure for a year, and the current role I have is Lead Software Engineer. I???ve been in the field for about 27 years. As a developer and as an architect, I spent a lot of time designing cloud-based microservices the past several years. Security is a big part of that, especially in the healthcare field given the sensitive nature. As a developer, we feel a lot of pressure to get things done, especially with the SAFe Agile model, and I???ve had experiences where security runs the risk of being overlooked ??? which it shouldn???t be. So, I try to bring the focus on security to the work I do for Enrollment, and previously Billing, here at Adva |
Vulnerability Guideline | ||
|
2021-01-26 12:06:18 | Did You Read Our Most Popular 2020 Blog Posts? (lien direct) |  What was top of mind for your peers regarding AppSec in 2020?
Yes, we realize no one really wants a 2020 retrospective ??? who wants to look back at that mess? But we are going to carry on with our annual look-back at our most popular blogs from the previous year. We always gain a lot of insight with this exercise ??? we find out what resonated with security professionals and developers, uncover trends, and learn what people have questions or concerns about. We hope you find this valuable too.
So what were the hot AppSec topics in 2020? Topping the list: Developer security training, best practices made practical, open source security, technical details on vulnerabilities, and, of course, the sudden shift to remote work and a digital world last March. Did you catch all these popular blog posts?
Developer security training
Our new Security Labs offering was a hot topic last year. Clearly, training developers on secure coding is a requirement and a concern for many. If you want to see what Security Labs is all about, check out the Community Edition. Developers can use it to learn to code securely by hacking and patching real apps, at no cost.
Announcing Veracode Security Labs Community Edition
Stay Sharp and Squash Security Debt With Veracode Security Labs
Our survey report with ESG covered some of the pain points organizations are facing regarding security training, and blogs on that topic were in our most-viewed list as well.
16% of Orgs Require Developers to Self-Educate on Security
How 80% of Orgs Can Overcome a Lack of Training for Developers
Best practices for the rest of us
Our guide on AppSec best practices vs. practicalities and its associated blog were among our most-read content pieces last year. Highlighting not only what to strive for, but also where to start, with application security seemed to resonate with many.
Best Practices and Practical Steps to Guide Your AppSec Journey
Securing open source code
As with the past several years, open source security was one of the most popular topics. The first open source edition of our annual State of Software Security report got a lot of attention in 2020. Take a look at the report to get the results of our analysis of 351,000 external libraries in 85,000 apps. We unearthed some really interesting data about the number of dependencies in open source libraries, and about challenges and best practices in securing them.
Announcing Our State of Software Security: Open Source Edition
Breaking Down Risky Open Source Libraries by Language
Details on vulnerabilities and secure coding
Blogs that take a technical deep dive into particular vulnerabilities typically resonate with our audience, and last year was no exception. Our blog posts on spring view manipulation vulnerability and preventing sensitive data exposure got a lot of attention in 2020.
Write Code That Protects Sensit |
Vulnerability Patching | ||
|
2021-01-26 11:37:41 | Which AppSec Testing Type Should You Deploy First? (lien direct) |  The gold standard for creating an application security (AppSec) program is ??? and always will be ??? to follow best practices. By following preestablished and proven methods, you can ensure that you are maximizing the benefits of your AppSec program.
Unfortunately, time, budget, culture, expertise, and executive buy-in often restrict organizations from following best practices. But that doesn???t mean that you can???t create an impactful AppSec program. You should aim to follow best practices but ??? when you can???t ??? there are practical first steps you can take to position your program for future improvements.
Ideally, you should be using every testing type ??? static analysis, dynamic analysis, software composition analysis, interactive application security testing, and penetration testing.
Each AppSec test has its own strengths and weaknesses, with no one tool able to do it all. If you choose not to employ a specific test, you could be leaving your application vulnerable. For example, if you don???t employ software composition analysis, you may miss vulnerabilities in your third-party code. And if you don???t employ dynamic analysis, you could miss configuration errors. But by using all of the testing types together, you can drive down risk across the entire application lifetime from development to testing to production.
If you don???t have the funds or support to employ every AppSec testing type, you should always begin with the test(s) that will have the most impact, in the shortest amount of time, for the least amount of money. This will depend on factors like your release cadence, risk tolerance, and budget.
For organizations releasing software less than four times a year, manual AppSec scans will probably suffice. But if you release software daily or weekly ??? likely in a CI/CD fashion ??? you will need to automate your AppSec scans with each code commit.
You also need to consider the speed of different scan types. Static analysis can provide immediate feedback with each commit. Penetration tests, on the other hand, are much slower because they rely on a human pen-tester to review the code.
But speed isn???t the only concern. You also need to consider the risk of your applications. An application housing sensitive data ??? like banking information ??? needs to undergo more in-depth AppSec tests than a lower-risk application. In-depth AppSec tests, like penetration testing, may take longer but they are critical in preventing cyberattacks. It really comes down to weighing the risk vs. time to market. In some instances, it may be okay to release software with low- or medium-severity risks. But for high-severity risks, you should break the build until the vulnerability is remediated.
Budget is also a major factor. Penetration tests are considerably more expensive than other testing types. So, if you???re on a tight budget, frequent pen tests may not be feasible. You might be better off pen-testing on an annual or bi-annual basis.
Once you???ve successfully implemented the AppSec testing type(s) that provides the most value to your organization, it???s time to start making the case for additional scans. As always, consider your budget, risk tolerance, and technology when adding to your AppSec mix.ﾂ?
To learn more about AppSec best practices and practical first steps, check out our guide, Application Security Best Practices vs. Practicalities: What to Strive for and Where to Start, and keep an eye out for our upcomin |
Tool Vulnerability | ||
|
2021-01-19 13:02:38 | Retail and Hospitality Sector Has Impressive Fix Rate, but Room to Improve (lien direct) |  Over the past year, the retail and hospitality industries have been forced to adapt to the ???new normal.??? Since lockdowns and health concerns have prevented or dissuaded in-person shopping or dining, the new normal has been e-commerce. Smaller businesses not equipped for the increase in e-commerce have had to undergo rapid digital transformation in order to stay afloat. But, unfortunately, e-commerce was not the only thing to increase in 2020. Cyberattackers have been taking advantage of the influx of digital activity.
This is especially concerning because, according to our recent State of Software Security (SOSS) report, 76 percent of applications in the retail and hospitality sector have a security vulnerability and 26 percent have high-severity security vulnerabilities.
But, on a positive note, our SOSS findings also revealed that when compared to other industries, retail and hospitality have the second-best fix rate and the best median time to remediate security flaws. This means that even though the industries might have a higher than usual number of flaws, they are quick to act and remediate those flaws. As Chris Eng, Chief Research Officer at Veracode explains, ???If retailers are constantly having to push out code containing business logic to support new promotions, that might account for the fix times.???
The SOSS report also examined how 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 organization or application size, application age, or flaw density ??? can affect 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, scanning frequently and steadily, and utilizing APIs ??? can also influence how long it takes to remediate security flaws.
For the retail and hospitality industries, we found that they have a low flaw density relative to other sectors, but the applications tend to be old and larger. We also found that the sector is not consistently using DevSecOps best practices like scanning frequently in an automated way. If developers start following the best practices regularly, the retail and hospitality industries can remediate flaws and chip away at security debt faster.
Flaws that the retail and hospitality sector should keep a close eye on include encapsulation, SQL injection, and credential management issues. These flaw types seem to be more prevalent in the retail and hospitality sector compared to other industries, and they can lead to a serious breach. In fact, injection flaws are considered by OWASP Top 10 to be the number one, most critical security risk to web applications.
For more information on software security trends in the retail and hospitality industries, check out The State of Software Security Industry Snapshot.
ﾂ? |
Vulnerability Guideline | ||
|
2020-12-21 13:30:38 | Fixing CRLF Injection Logging Issues in Python (lien direct) |  It can sometimes be a little challenging to figure out specifically how to address different vulnerability classes in Python. This article addresses one of the top finding categories found in Python, CWE 117 (also known as CRLF Injection), and shows how to use a custom log formatter to address the issue. We???ll use this project, which deactivates or deletes user accounts from the Veracode platform, to illustrate the functionality.
The vulnerability
CWE 117 (sometimes classified as CWE 93) is (normally, see note below) a medium severity finding that compromises the integrity of logging information by allowing an attacker to insert extra log statements, corrupt the logs so that they become unreadable, or even inject malicious code into the logs (useful if the log will be read through a web user interface). The attacker does this by inserting data containing carriage return and line feed (CRLF) characters, causing the appearance of a new logging statement.
Note on classification: CWE 93 refers to a broader set of weaknesses with handling content containing CRLF characters. It applies to logs and also to HTTP headers (CWE 113), sending email messages, or any output format where carriage returns and line feeds are significant characters; CWE 117 is the log-specific version of it. This article focuses specifically on issues where CRLF injection occurs in a logging context (CWE 117).
Example
This code snippet is vulnerable to CRLF injection:
import logging
import sys
import anticrlf
logger = logging.getLogger(__name__)
logging.basicConfig(level=logging.DEBUG, stream=sys.stderr)
... # additional logger setup
dangerous_value = "This line splits\r\nthe log entry by including CRLF"
logger.warn("The value of dangerous_value is {}".format(dangerous_value))
# WARNING:__main__:The value of dangerous_value is This line splits
# the log entry by including CRLF
# Note how the above ^ makes two lines, messing up log integrityThe fix
Before we get into the fix, it???s worth noting that not every application has a strong requirement for log integrity ??? a local command line script may not require as much attention to this vulnerability category as a system where auditing is a requirement and that takes input from multiple users. See also the note on severity below.
Assuming that log integrity is important for your application (and in most cases it probably is), the strategy for fixing CRLF injection vulnerabilities is to sanitize all user inputs, ensure that you use a consistent character encoding throughout the application (to avoid problems from canonicalization), and escape output. Dealing with the first two issues is beyond the scope of this article, but applying an output escaping strategy is pretty straightforward by using a logging formatter. For the purposes of this blog, we???ll use logging-formatter-anticrlf from Veracode Research; see the Alternatives section for some other approaches you could take.
The logging-formatter-anticrlf library functions as a drop-in logging formatter, but it escapes carriage returns and line feeds in the output. Darren???s readme shows how to use the library for stream-based logging; the project above shows an example of using it with logging to a file. Here???s how:
First, we install logging-formatter-anticrlf using pip install logging-formatter-anticrlf.
|
Vulnerability | ||
|
2020-12-16 10:41:10 | Defense in Depth: Why You Need DAST, SAST, SCA, and Pen Testing (lien direct) |  When it comes toﾂ?applicationﾂ?security (AppSec),ﾂ?most experts recommend usingﾂ?Dynamic Application Security Testingﾂ?(DAST)ﾂ?andﾂ?Static Application Security Testingﾂ?(SAST)ﾂ?as ???complementary??? approaches for robust AppSec. However, these experts rarely specifyﾂ?howﾂ?to run them in a complementary fashion.ﾂ?
At Veracode, we use SAST, DAST,ﾂ?SCA,ﾂ?andﾂ?penﾂ?testing as theﾂ?fourﾂ?pillars of ourﾂ?defenseﾂ?in-depthﾂ?strategy to deliver a ???secure-by-design??? AppSec methodology across the entireﾂ?softwareﾂ?developmentﾂ?lifeﾂ?cycle.ﾂ?ﾂ?
Manualﾂ?penetrationﾂ?testingﾂ?
Most organizations start their AppSec journey by runningﾂ?manualﾂ?penetrationﾂ?testsﾂ?(MPT).ﾂ?Penetration testing is necessary to catch vulnerability classes,ﾂ?such as authorization issues and business logic flaws,ﾂ?that cannot be found through automated assessments alone. Expertly trained pen testersﾂ?canﾂ?reviewﾂ?an entireﾂ?environment,ﾂ?rather than just the application,ﾂ?and canﾂ?follow or break the workflows in a way that is difficult forﾂ?automation to replicate.ﾂ?Additionally, pen testing is requiredﾂ?to comply with regulations such asﾂ?PCI DSS, HIPAA, GLBA, FISMA, and NERC CIP.ﾂ?
However,ﾂ?penﾂ?testing is only one assessment type and can bottleneck developmentﾂ?velocityﾂ?because it is a manual process.ﾂ?ﾂ?
How does Dynamic Analysis work?ﾂ?
Dynamicﾂ?applicationﾂ?securityﾂ?testingﾂ?(DAST)ﾂ?isﾂ?an AppSec assessment thatﾂ?scans all applications and interconnected structures in a running environment without looking deeply into source code. The results of ???outside-in???ﾂ?dynamicﾂ?scanningﾂ?help prioritizeﾂ?the remediation ofﾂ?exploitable vulnerabilitiesﾂ?and immediately reduce AppSec risk as they are fixed. However, it can be challenging to pinpoint theﾂ?exactﾂ?line of code toﾂ?work onﾂ?using only DAST.ﾂ?This assessment on its own is limited by the configuration of your scanner and what you choose to test. If you don???t properly configure your scans,ﾂ?you may miss vulnerabilities and have a false sense of security.ﾂ?
Additionally, since theﾂ?applicationﾂ?isﾂ?scannedﾂ?towards the end of theﾂ?SDLC,ﾂ?there???s more pressure on development teams to remediate the difficult-to-find vulnerabilities quickly.ﾂ?This is usuallyﾂ?whereﾂ?frictionﾂ?between development and security increases,ﾂ?often resulting in unmitigated risk.ﾂ?ﾂ?
How does Static Analysis work?ﾂ?
Staticﾂ?applicationﾂ?securityﾂ?testingﾂ?(SAST)ﾂ?is an AppSec assess |
Vulnerability Threat | ||
|
2020-12-11 11:15:19 | How Password Hashing Algorithms Work and Why You Never Ever Write Your Own (lien direct) |  Are you fascinated with cryptography? You're not alone: a lot of engineers are. Occasionally, some of them decide to go as far as to write their own custom cryptographic hash functions and use them in real-world applications. While understandably enticing, doing so breaks the number 1 rule of the security community:??ｯdon't write your own crypto.ﾂ?
How do hashing algorithms work and what's special about password hashing? What does it take for an algorithm to get ready for widespread production use? Is security through obscurity a good idea? Let's see.ﾂ?
How does password hashing work?ﾂ?
Before storing a user's password in your application's database, you're supposed to apply a cryptographic hash function to it. (You're not storing passwords in plain text, right? Good. Just asking.)ﾂ?
Any cryptographic hash function converts an arbitrary-length input (a.k.a. "message") into a fixed-length output (a.k.a. "hash", "message digest"). A??ｯsecure cryptographic hash function??ｯmust be:ﾂ?
Deterministic: hashing the same input should always render the same output.ﾂ?
One-way: generating an input message based on a given output should be infeasible.ﾂ?
Collision-resistant: finding two input messages that hash to the same output should also be infeasible.ﾂ?
Highly randomized: a small change in input should lead to a significant and uncorrelated change in output (a.k.a. "the avalanche effect"). Without this property, applying cryptoanalysis methods will allow making predictions about the input based on the |
Vulnerability Guideline | ★★★ | |
|
2020-12-09 16:34:28 | Is Your Language of Choice a Major Flaw Offender? (lien direct) |  In volume 11 of our annual State of Software Security (SOSS) report, we uncovered some valuable nuggets of information about how you, the innovative developers of our world, can craft more secure code. For example, did you know that scanning via API improves the time to remediate 50 percent of security flaws by about 17 days, or that C++ and PHP languages have an alarmingly high number of severe security flaws and need greater attention?
It???s not enough to simply stay on top of the biggest flaw offenders and the latest trends. If you want to improve the quality of your code, you need to take that information and apply it to the tools, processes, and languages that you use every day. Knowing these trends in application security before you sit down to code means you???re prepared to fix them quickly or ??? even better ??? prevent them altogether.
This year???s edition of SOSS comes equipped with a standalone report and an interactive heat map to help you do just that; our Flaw Frequency by Language infosheet explores vulnerability trends in various common languages to highlight everyday risks so that you can get ahead of them. This breakdown of the data, which includes information from 130,000 application scans, tells us which languages tend to house the most critical flaws:
 ???
If C++, PHP, .Net, or Java are your languages of choice, take note ??? they???re prone to some of the riskiest vulnerabilities around. In fact, a whopping 59 percent of C++ applications have high and very high-severity flaws, with PHP coming in at a close second place.
 ???
The worm map above is a visual representation of just how prevalent certain flaws are in the languages they impact the most. You can see that (despite being in second place) PHP has a high frequency of risky flaws like Cross-Site Scripting (XSS), cryptographic issues, directory traversal, and information leakage exploits. Another interesting note; you can tell from this worm map that Python and JavaScript are quite similar when it comes to flaw frequency, with fewer occurrences of those high-risk flaws.
 ???
Further breaking down flaw frequency by language, our interactive heat map is a helpful tool for understanding just how risky some of these exploits can be in your languages of choice. Simply click through the vulnerabilities to see the data, gain insight into why these flaws are so dangerous, and learn how to prepare yourself for tackling |
Tool Vulnerability | ★★★ | |
|
2020-11-16 14:06:22 | State of Software Security v11: How to Use the Findings (lien direct) |  As a security professional reading through version 11 of our State of Software Security (SOSS) report, the first statistic that probably stands out to you is that 76 percent of applications have security flaws. It???s encouraging to see that only 24 percent of those security flaws are high-severity, but ultimately, having security flaws in more than three-fourths of applications means there is still work to be done.
How can you better secure your applications?
For this year???s SOSS report, we decided to look at the effects of ???nature?????? factors we can???t change like application size or age ??? versus ???nurture??? ??? factors we can change like scan frequency ??? to see how they impact application security. The findings, if put into practice, can significantly improve the security health of your applications.
1. Use DAST with SAST.
SOSS research shows that when using dynamic application security testing (DAST) in conjunction with static application security testing (SAST), organizations are able to find and fix flaws almost 25 days faster. Why is this? Perhaps because dynamic scanning highlights to developers that a vulnerability does, in fact, have ???real-world??? risk.
2. Scan frequently and on a regular cadence.
SOSS v11 found that organizations that scan their applications infrequently (less than 12 times in a year) spent about 7 months to close half their open findings, while organization that scan their applications at least daily reduced time to remediation by more than a third, closing 50 percent of flaws in 2 months. Likewise, organizations that scan their applications on a steady cadence reduced their time to remediation by 15.5 days. To improve scan frequency and cadence, consider automating application security (AppSec) scans into developers existing processes.
3. Integrate security testing with the API.
Those scanning via API ??? and therefore in an integrated and automated way ??? address half their security findings 17.5 days faster than those not scanning via API.
4. Use SCA with SAST.
Just as we highlighted the benefits of using DAST with SAST, it???s important to use software composition analysis (SCA) with SAST. Why? First, this year???s SOSS report found that 97 percent of the typical Java application is made up of third-party libraries and that almost one-third of applications have more security findings in third-party libraries than native codebase. If you only employ SAST, your attack surface is a lot bigger than you think. In addition, this year???s research found that those scanning with both static analysis and software composition analysis improve time to remediation by an average of 6 days.
What flaw types should you keep an eye on?
As a security professional, you???re likely familiar with the OWASP Top 10 |
Vulnerability | ||
|
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-29 13:04:48 | A Software Security Checklist Based on the Most Effective AppSec Programs (lien direct) |  Veracode???s Chris Wysopal and Chris Eng joined Enterprise Strategy Group (ESG) Senior Analyst Dave Gruber and award-winning security writer and host of the Smashing Security podcast, Graham Cluley, at Black Hat USA to unveil the findings from a new ESG research report, Modern Application Development Security. The research is based on a survey of nearly 400 developers and security professionals, which explored the dynamic between the roles, their trigger points, the extent to which security teams understand modern development, and the buying intentions of application security (AppSec) teams.
As the presenters went through the data, it led to a larger discussion about AppSec best practices and what steps organizations can take to mature their programs. Here are the best practices laid out during the presentation as an easy-to-follow checklist as well as supporting data from the ESG report.
Application security controls are highly integrated into the CI/CD toolchain.
In the ESG survey, 43 percent of organizations agreed that DevOps integration is most important to improving AppSec programs, but only 56 percent of respondents answered that they use a highly integrated set of security controls throughout their DevOps process. Integrating security measures into the CI/CD toolchain not only makes it easier for developers to run AppSec tests, but it also helps organizations discover security issues sooner, which speeds up time to deployment.
Application security best practices are formally documented.
In order to have a successful AppSec program, everyone needs to be on the same page regarding best practices. The CISO should help facilitate the formal documentation of AppSec best practices. Developers and security professionals can reference the list and use it to guide their decisions.
Application security training is included as part of the ongoing development security training program.
Developers have been increasingly tasked with implementing security measures, including writing secure code and remediating vulnerabilities. Most developers don???t receive secure code training courses in college, so it is up to organizations to offer security training. But according to the survey, more than 20 percent of organizations only provide training when developers join the team.
Developers should have multiple, at-leisure training opportunities throughout the year, like virtual or hands-on programs ??? such as Veracode Security Labs. Chris Wysopal pointed out the importance of human touchpoints as part of ongoing developer training. If someone is checking in on developers to make sure they???re completing their training, they???ll likely take it more seriously. Consider a security champions program. The security champions are developers who have an interest in learning about security. If you have at least one security champion on every scrum team, that person can help ensure that their peers are up to speed on the latest security training and best practices.
Ongoing developer security training includes formal training programs, and a high percentage of developers participate.
At-leisure security training is a great way for developers to learn on their own time. But it is also important to implement formal security training with a set completion date and a skills assessment. Without formal security training, developers may not develop the skills they need to write secure code and remediate vulnerabilities. This could lead to slower and more expensive deployments because of rework or vulnerable code being pushed to production.
Accordin |
Tool Vulnerability Guideline | Uber | |
|
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 | |
|
2020-09-21 13:35:42 | Focus on Fixing, Not Just Finding, Vulnerabilities (lien direct) |  When investing in an application security (AppSec) program, you expect to see a return on your investment. But in order to recognize a return, your organization needs to determine what success looks like and find a way to measure and prove that the program is meeting your definition of success.
For those just starting on their AppSec journey, success might be eliminating OWASP Top 10 vulnerabilities or lowering flaw density. But as you begin to mature your program and work toward continuous improvements, you should start measuring your program against key performance indicators (KPIs) like fix rate. Fix rate is used to indicate how fast your organization is closing ??? or remediating ??? flaws. The formula for fix rate is the number of findings closed divided by the number of findings open. As you can see in the diagram below, of the 6,609 flaws, 2,581 flaws areﾂ?open and 4,028 are closed. This means that flaws are remediated at a rate of 16 percent. The faster your organization fixes flaws, the lower the chances of an exploit. For the sake of continuous improvement, you should be finding that your organization is improving its fix rate by remediating flaws faster year over year.
ﾂ?
Using Veracode Analytics to examine fix rate and prove AppSec success.
Using Veracode Analytics custom dashboards, you can examine your total fix rate or break it out by application, scrum team, business unit, or geographical location. These dashboards can be shared with stakeholders and executives to show areas where your fix rate is improving or areas that need additional attention and resources.
When examining fix rate across applications, you should be finding that your more critical applications have a better fix rate. If that???s not the case, you need to be examining the application security policies you have in place for fixing flaws. High-severity and highly exploitable flaws should be prioritized over low-severity flaws with a lower chance of exploitability. The same logic applies to applications: High-risk applications storing large amounts of sensitive data should be prioritized.
When examining the fix rate across scrum teams and locations, you should find that teams and geographical locations are continuously improving their fix rate. If not, you should use the data to tailor future security trainings or to ask stakeholders and executives for additional resources.
How does fix rate impact return on investment?
By remediating flaws faster, you are reducing the chance of an exploit which could cost your business thousands ??? even millions ??? to resolve. For example, Capital One had a third-party vulnerability that was not remediated, and it led to a massive data breach which exposed its customer???s social security numbers and bank account numbers. It cost Capital One approximately 150 million dollars to resolve the matter.
Faster time to remediation also means faster time to production. Once developers fix all of the flaws defined in their policy, code can be moved to production. If code is moved to production at a faster rate, an organization ??? and its customers ??? can start recognizing value from the application sooner.
ﾂ?
For additional methods on proving AppSec success, check out our re |
Data Breach Vulnerability | ||
|
2020-09-15 09:53:29 | Write Code That Protects Sensitive User Data (lien direct) |  Sensitive data exposure is currently at number 3 in the??ｯOWASP Top 10??ｯlist of the most critical application security risks.
In this blog post, we will describe common scenarios of incorrect sensitive data handling and suggest ways to protect sensitive data. We will illustrate our suggestions with code samples in C# that can be used in ASP.NET Core applications.
What is sensitive data?
OWASP lists passwords, credit card numbers, health records, personal information and business secrets as sensitive data.
Social security numbers, passwords, biometric data, trade memberships and criminal records can also be thought of at sensitive data.
What exactly sensitive data means for you will depend on:
Laws and industry regulations such as EU's General Data Protection Regulation (GDPR) or the UK's Data Protection Act (DPA) that govern the use of "personal data".
Business requirements. The law may not enforce strict measures around sensitive data that your application creates or stores for its users, but breaching that data would still hurt your users and, by extension, your business.
In software applications, we can think of sensitive data as:
Most user data (for example, names listed in public user profiles may not be sensitive).
Application data (such as session IDs and encryption keys) that helps protect user data from being exposed.
Various sources and authorities may have different definitions of sensitive data. However, if you're a business that develops an application that works with user data, it's in your best interest to use a broad interpretation of "sensitive data" and do your best to protect it.
What vulnerabilities can lead to sensitive data exposure?
Let's discuss some of the most common vulnerabilities that can expose sensitive user data.
Leaking access control that enables forced browsing to restricted content
Due to inadequate access control, users who are not expected to see sensitive data may in fact be able to access it, even though the data is not referenced by the application in any way. An attack called force browsing takes advantage of this situation.
Imagine you're a regular user of a web application, and when you look around the UI, you don't see any administrative functionality available. Still, if you manually enter a URL that you think may be available to admin users (such as??ｯhttps://www.myapp.com/admin), you do see the admin UI. This is forced browsing: the application didn't guide you to a restricted resource, but neither did it prevent you from accessing it.
Improperly managed sessions
When sessions are managed improperly, session IDs of authenticated users are at risk of being exposed, and attackers can take advantage of this to impersonate legitimate users. Two common attacks that are made possible by improper session management are session hijacking and session fixation. Attacks like these can have a severe impact if targeted at privileged accounts and can cause massive leakage of sensitive data.
One major reason why sessions can be mismanaged is that developers sometimes write their custom authentication and session management schemes instead of using battlefield-tested solutions, but doing this correctly is hard.
Insecure cryptographic storage
Insecure cryptographic storage??ｯrefers to unsafe practices of storing sensitive data, most prominently user passwords. This is not about not protecting data at all, which results in storing passwords as plain text. Instead, this is about applying a wrong cryptographic process or a surrogate, such as:
|
Vulnerability Guideline | ||
|
2020-09-11 15:42:17 | Why Application Security is Important to Vulnerability Management (lien direct) |  It was the day before a holiday break, and everyone was excited to have a few days off to spend with friends and family. A skeleton crew was managing the security operations center, and it seemed as though every other team left early to beat the holiday traffic. Every team other than the vulnerability management (VM) team that is. Just before it was time to leave for the day, and the holiday break, the phone rang. We were notified of a zero-day vulnerability, and our CISO requested a report on the location of the risk within the enterprise. Does this sound familiar?
This happened to me. I was part of the vulnerability management team leading the web application scanning program for a Fortune 100 company. When they announced a major struts vulnerability targeting SWIFT, my CISO wanted to know exactly where we could find it in our applications. As part of our prioritization efforts at the time, and according to our internal security policy, the VM team was only scanning our external applications dynamically. Sure, the software development lifecycle (SDLC) process included rigorous testing throughout the different stages, however, the data collected in some cases was point-in-time, and access to this data, if it persisted, was not accessible to the VM team.
One of the main reasons we continuously analyze our assets is to be aware. You don???t just want to know what vulnerabilities are present within your servers, containers, applications, and libraries. You also want to know what else is out there so when your CISO asks you where the zero-day vulnerability exists in your enterprise, you can quickly have an informed answer without having to rescan every single asset in your inventory to provide a report.
This is why the VM and security function need to be part of the development process. It???s not because security wants to be the persistent nag always asking, ???Did you scan it????, ???Did you scan it????, but it is their job to be proactive. Yes, I said it. Vulnerability Management is proactive. I can???t begin to tell you how many times I???ve heard people say, ???What???s the point of vulnerability management anyways? It???s just a reactive response to the inevitable.??? Collecting intelligence from your assets is a proactive measure that allows you to quickly assess the risk and remediate or mitigate as needed.ﾂ?
At Veracode, we provide you with the data from your application security program so it can be utilized as part of your vulnerability management program. Do you need to find where struts exist in your applications? No problem. With software composition analysis, we are able to identify all the libraries you are calling within your application, and we are even able to see what those libraries are calling. If Struts or any other library that poses a risk to your application is identified, we are going to let you know. Whether it be a Common Vulnerability and Exposure (CVE) finding or a Common Weakness Enumeration (CWE) category of flaw, we can identify it using static or dynamic analysis. We can then give you this intelligence so that the next time you are asked where the risk is, you can quickly pull from the data you have proactively collected and provide your CISO the risk data necessary to make quick, informed decisions.
To learn more about managing vulnerabilities, check out our comprehensive application security solutions. ﾂ? |
Vulnerability Guideline | ||
|
2020-09-03 11:31:07 | Spring View Manipulation Vulnerability (lien direct) |  In this article, we explain how dangerous an unrestricted view name manipulation in Spring Framework could be. Before doing so, lets look
at the simplest Spring application that uses Thymeleaf as a templating engine:
Structure:
 HelloController.java:
@Controller
public class HelloController {
@GetMapping("/")
public String index(Model model) {
model.addAttribute("message", "happy birthday");
return "welcome";
}
}
Due to the use of @Controller and @GetMapping("/") annotations, this method will be called for every HTTP GET request for the root url ('/'). It does not have any parameters and returns a static string "welcome". Spring framework interprets "welcome" as a View name, and tries to find a file "resources/templates/welcome.html" located in the application resources. If it finds it, it renders the view from the template file and returns to the user. If the Thymeleaf view engine is in use (which is the most popular for Spring), the template may look like this:
welcome.html:
Spring Boot Web Thymeleaf Example
Thymeleaf engine also support file layouts. For example, you can specify a fragment in the template by using and then request only this fragment from the view:
@GetMapping("/main")
public String fragment() {
return "welcome :: main";
}
Thymeleaf is intelligent enough to return only the 'main' div from the welcome view, not the whole document.
From a security perspective, there may be a situation when a template name or a fragment are concatenated with untrusted data. For example, with a request parameter:
@GetMapping("/path")
public String path(@RequestParam String lang) {
return "user/" + lang + "/welcome"; //template path is tainted
}
@GetMapping("/fragment")
public String fragment(@RequestParam String section) {
return "welcome :: " + section; //fragment is tainted
}
The first case may contain a potential path traversal vulnerability, but a user is limited to the 'templates' folder on the server and cannot view any files outside it. The obvious exploitation approach would be to try to find a separate file upload and create a new template, but that's a different issue.Luckily for bad guys, before loading the template from the filesystem, Spring ThymeleafView class parses the template name as an expression:
try {
// By parsing it as a standard expression, we might profit from the expression cache
fragmentExpression = (FragmentExpression) parser.parseExpression(context, "~{" + viewTemplateName + "}");
}
So, the aforementioned controllers may be exploited not by path traversal, but by expression language inj |
Vulnerability Guideline | ||
|
2020-07-30 10:25:39 | Announcing Veracode Security Labs Community Edition (lien direct) |  We recently partnered with Enterprise Strategy Group (ESG) to survey software development and security professionals about modern application development and how applications are tested for security. The soon-to-be-announced survey found that 53% of organizations provide security training for developers less than once a year, which is woefully inadequate for the rapid pace of change in software development. At the same time, 41% say that it???s up to security analysts to educate developers to try to prevent them from introducing significant security issues. So, where???s the disconnect?
Communication breakdowns and misaligned training priorities between security and development teams are part of the problem. As developers are being asked to ???Shift Left??? to take on more responsibility for secure code earlier in the software development lifecycle, it???s increasingly more important for developers to get the training they need to not just create world-class applications ??? ones that have security designed in from the beginning.
Enterprise-grade tools for all developers
Veracode Security Labs Enterprise Edition is perfect for engineering teams, but we wanted every individual developer to have access to the same quality of training, from casual hobbyists to professionals interested in improving their secure coding skills. I???m excited to announce Veracode Security Labs Community Edition, where developers worldwide can hack and patch real applications to learn the latest tactics and security best practices with guidance while exploring actual code on their own time; and it???s free!
With Veracode Security Labs Community Edition, you now have the tools you need to close any gaps in security knowledge that are holding you back. It???s a module that fits within the Veracode Developer Training product family, featuring tools and robust programs built with interactivity in mind so that developers can get their hands on a practical training tool at a moment???s notice.
Here are the differences between the Community Edition and Enterprise Edition:
 ???
While the Enterprise Edition has features that support the efforts of development teams with full compliance-based curricula, rollout strategies, and progress reporting, the Community Edition offers selected topics and one-off labs for individuals who are looking to strengthen their security knowledge. Though there are differences that enable scalability for organizations and teams, the benefits for individual developers remain the same:
The ability to exploit and remediate real-world vulnerabilities to learn what to look for in insecure code.
Fast and relevant remediation guidance in the context of the most popular programming languages.
Easy and fun hands-on training that provides professional growth.
Improved security knowledge while building confidence through interactive trial and error.
When you practice breaking and fixing real applications using real vulnerabilities, you become a sharper, more efficient developer ??? especially with a variety of challenges to choose from as you go. We plan to expand the number of labs and challenges over time but initially, the Community Edition will cover topics ranging from beginner to advanced, including:
|
Hack Tool Vulnerability | ★★★★ |
To see everything:
Our RSS (filtrered)
