What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2024-05-14 13:58:40 | Échelle DevSecops avec des tests de sécurité des applications dynamiques (DAST) Scaling DevSecOps with Dynamic Application Security Testing (DAST) (lien direct) |
Le rôle du DAST dans les pratiques de DevseCops modernes
Dans le paysage rapide en évolution du développement de logiciels dirigés par l'IA, DevSecops aide à renforcer la sécurité et la qualité des applications.Les tests de sécurité des applications dynamiques (DAST) sont un outil clé qui aide à mettre à l'échelle votre programme DevSecops en facilitant des tests de sécurité continus et précis sur les applications en cours d'exécution.
Dast simule les attaques du monde réel, vous permettant d'identifier les faiblesses de sécurité et d'évaluer les défenses de votre application en réponse aux attaques réelles.Laissez \\ explorer certaines meilleures pratiques exploitables pour tirer parti de la DAST efficacement et renforcer vos initiatives DevSecops.
Intégration transparente dans les pipelines CI / CD
L'incorporation de scans DAST directement dans vos pipelines d'intégration et de livraison continue (CI / CD) aide à détecter les vulnérabilités d'exécution plus tôt dans votre processus de développement.Cette intégration permet des tests de sécurité automatique, avec chaque mise à jour de code, donnant aux développeurs des commentaires immédiats.Attraper des vulnérabilités tôt signifie moins…
The Role of DAST in Modern DevSecOps Practices In the swiftly evolving landscape of AI-driven software development, DevSecOps helps strengthen application security and quality. Dynamic Application Security Testing (DAST) is a key tool that helps scale your DevSecOps program by facilitating continuous and accurate security tests on running applications. DAST simulates real-world attacks, enabling you to identify security weaknesses and evaluate your application\'s defenses in response to actual attacks. Let\'s explore some actionable best practices to leverage DAST effectively and strengthen your DevSecOps initiatives. Seamless Integration into CI/CD Pipelines Incorporating DAST scans right into your continuous integration and delivery (CI/CD) pipelines helps detect runtime vulnerabilities earlier in your development process. This integration allows for automatic security testing, with every code update, giving developers immediate feedback. Catching vulnerabilities early means less… |
Tool Vulnerability | ||
|
2024-03-28 10:05:47 | Les clients Veracode sont protégés des perturbations NVD Veracode Customers Shielded from NVD Disruptions (lien direct) |
L'Institut national américain des normes et de la technologie (NIST) a presque complètement cessé d'analyser de nouvelles vulnérabilités (CVE) répertoriées dans sa base de données nationale de vulnérabilité (NVD).Au cours des six premières semaines de 2024, le NIST a analysé plus de 3 500 CVE avec seulement 34 cves en attente d'analyse.1 Depuis le 13 février, cependant, près de la moitié (48%) des 7 200 cves reçus cette année par le NVD attendent toujours une analyse.2 LeLe nombre de CVE analysés a chuté de près de 80% à moins de 750 CVE analysés.Outre une vague référence à l'établissement d'un consortium, les raisons de cette perturbation restent un mystère.
Heureusement, les clients Veracode n'ont pas besoin de se soucier de cette perturbation car ils ont accès à la base de données propriétaire de Veracode \\.Depuis l'avis du 13 février, Veracode a publié plus de 300 CVE.Sur ces 300+, NVD a analysé moins de 15 de ces CVE.Lisez la suite pour savoir comment Veracode SCA fonctionne sans NVD à fournir une analyse CVE.
Analyse NVD…
The US National Institute of Standards and Technology (NIST) has almost completely stopped analyzing new vulnerabilities (CVEs) listed in its National Vulnerability Database (NVD). Through the first six weeks of 2024, NIST analyzed over 3,500 CVEs with only 34 CVEs awaiting analysis.1 Since February 13th, however, nearly half (48%) of the 7,200 CVEs received this year by the NVD are still awaiting analysis.2 The number of CVEs analyzed has dropped nearly 80% to less than 750 CVEs analyzed. Other than a vague reference to establishing a consortium, the reasons behind this disruption remain a mystery. Thankfully, Veracode customers need not worry about this disruption because they have access to Veracode\'s proprietary database. Since the notice on February 13th, Veracode has released over 300 CVEs. Of these 300+, NVD has analyzed less than 15 of these CVEs. Read on to learn how Veracode SCA operates without NVD providing CVE analysis. NVD Analysis … |
Vulnerability | ★★★ | |
|
2024-03-26 14:45:35 | Résolution de défauts de script inter-sites simples avec correction de veracode Resolving Simple Cross-Site Scripting Flaws with Veracode Fix (lien direct) |
Dans le dernier blog sur la fixation des vulnérabilités avec Veracode Fix, nous avons examiné la correction de l'injection SQL dans une application Java.Depuis lors, nous avons publié Fix Prise en charge de Python (et PHP) et lancé un nouveau plugin VS Code qui inclut la prise en charge de la correction.
Il semble donc approprié de chercher à résoudre un problème dans une application Python à l'aide de Veracode Fix dans le code VS IDE.Cette fois, laissez \\ examiner une simple faiblesse de script (XSS).
Qu'est-ce qu'une vulnérabilité XSS?
Une vulnérabilité XSS se produit lorsqu'un attaquant injecte du code malveillant dans un site Web de confiance, qui est ensuite exécuté par des utilisateurs sans méfiance.Cela peut entraîner un accès non autorisé, un vol de données ou une manipulation de sessions utilisateur.Les vulnérabilités XSS se trouvent couramment dans les champs de saisie, les sections de commentaires ou le contenu peu validé par l'utilisateur.Un exemple de démonstration simple consiste souvent à saisir le texte suivant dans un champ de saisie de l'utilisateur:
Si une demande ne désinfecte pas…
In the last blog on fixing vulnerabilities with Veracode Fix, we looked at SQL Injection remediation in a Java application. Since then, we have released Fix support for Python (and PHP) and launched a new VS Code plugin that includes support for Fix. It seems appropriate, therefore, to look at resolving a problem in a Python app using Veracode Fix in the VS Code IDE. This time let\'s examine a simple cross-site scripting (XSS) weakness. What is an XSS Vulnerability? An XSS vulnerability occurs when an attacker injects malicious code into a trusted website, which is then executed by unsuspecting users. This can lead to unauthorized access, data theft, or manipulation of user sessions. XSS vulnerabilities are commonly found in input fields, comments sections, or poorly validated user-generated content. A simple demonstration example is often to enter the following text in a user input field: If an application does not sanitize… |
Vulnerability | ★★★ | |
|
2024-03-13 11:17:26 | Un changement opportun: hiérarchiser la sécurité des logiciels dans le paysage numérique 2024 A Timely Shift: Prioritizing Software Security in the 2024 Digital Landscape (lien direct) |
La sortie du rapport technique de février 2024 de la Maison Blanche, de retour aux éléments constitutifs: un chemin vers des logiciels mesurables sécurisés, entraîne un changement en temps opportun dans la hiérarchisation de la sécurité des logiciels.Le logiciel est omniprésent, il devient donc de plus en plus crucial pour aborder la surface d'attaque en expansion, naviguer dans des environnements réglementaires complexes et atténuer les risques posés par des attaques sophistiquées de la chaîne d'approvisionnement des logiciels.
Soit \\ explorer les idées clés du rapport technique de la Maison Blanche et plonger dans les recommandations d'intégration de la sécurité dans le cycle de vie du développement logiciel (SDLC).
Sécuriser les blocs de construction du cyberespace: le rôle des langages de programmation
Le rapport de la Maison Blanche met l'accent sur le langage de programmation comme un élément de construction principal pour sécuriser l'écosystème numérique.Il met en évidence la prévalence des vulnérabilités de la sécurité mémoire et la nécessité d'éliminer de manière proactive des classes de vulnérabilités logicielles.Le rapport préconise l'adoption de…
The release of the February 2024 White House Technical Report, Back to the Building Blocks: A Path Towards Secure Measurable Software, brings about a timely shift in prioritizing software security. Software is ubiquitous, so it\'s becoming increasingly crucial to address the expanding attack surface, navigate complex regulatory environments, and mitigate the risks posed by sophisticated software supply chain attacks. Let\'s explore the key insights from the White House Technical Report and delve into recommendations for integrating security across the software development lifecycle (SDLC). Securing Cyberspace Building Blocks: The Role of Programming Languages The White House\'s report emphasizes the programming language as a primary building block in securing the digital ecosystem. It highlights the prevalence of memory safety vulnerabilities and the need to proactively eliminate entire classes of software vulnerabilities. The report advocates for the adoption of… |
Vulnerability Technical | ★★ | |
|
2024-03-04 13:29:00 | Intégration de Veracode Dast Essentials dans votre chaîne d'outils de développement Integrating Veracode DAST Essentials into Your Development Toolchain (lien direct) |
Dans le paysage numérique au rythme rapide d'aujourd'hui, les développeurs sont confrontés à une pression croissante pour fournir des applications sécurisées dans des délais serrés.Avec l'accent mis sur les versions plus rapides, il devient difficile de prioriser la sécurité et d'empêcher l'introduction des vulnérabilités dans les environnements de production.
L'intégration des tests de sécurité des applications dynamiques (DAST) dans votre pipeline CI / CD vous aide à détecter et à résoudre les vulnérabilités plus tôt, lorsqu'elles sont plus faciles à corriger.Dans ce blog, nous explorerons l'importance du DAST, fournirons un guide étape par étape sur la façon d'intégrer Veracode Dast Essentials dans votre pipeline CI / CD et de vous montrer comment commencer avec un essai gratuit de 14 joursDast Essentials aujourd'hui.
La signification du Dast
Dast joue un rôle vital dans la sécurisation des applications modernes.Clancs, selon le rapport sur l'état de la sécurité des logiciels de Veracode \\, 80% des applications Web ont des vulnérabilités critiques qui ne peuvent être identifiées que par des tests dynamiques.
En simulant les attaques du monde réel, Dast…
In today\'s fast-paced digital landscape, developers face increasing pressure to deliver secure applications within tight deadlines. With the emphasis on faster releases, it becomes challenging to prioritize security and prevent vulnerabilities from being introduced into production environments. Integrating dynamic application security testing (DAST) into your CI/CD pipeline helps you detect and remediate vulnerabilities earlier, when they are easier to fix. In this blog, we will explore the importance of DAST, provide a step-by-step guide on how to integrate Veracode DAST Essentials into your CI/CD pipeline, and show you how to get started with a free, 14-day trial of DAST Essentials today. The Significance of DAST DAST plays a vital role in securing modern applications. Shockingly, according to Veracode\'s State of Software Security Report, 80% of web applications have critical vulnerabilities that can only be identified through dynamic testing. By simulating real-world attacks, DAST… |
Vulnerability | ★★ | |
|
2024-02-28 07:00:00 | Stratégies basées sur les données pour une gestion efficace des risques d'application en 2024 Data-driven Strategies for Effective Application Risk Management in 2024 (lien direct) |
Les logiciels peu sûrs ont un impact significatif sur notre monde.Dans une récente déclaration, la directrice de la CISA, Jen Easterly, a déclaré: «Les caractéristiques et la vitesse de marché ont été prioritaires contre la sécurité, laissant notre nation vulnérable à la cyber invasion.Cela doit arrêter ... nous sommes à un moment critique pour notre sécurité nationale. »
Notre rapport State of Software Security 2024 explore un domaine clé que le compromis de la vitesse à la priorité au marché contre la sécurité a abouti: la dette de sécurité.Nos données montrent que près de la moitié des organisations ont des défauts persistants et à haute sévérité qui constituent une dette de sécurité critique.Nous révélons également ce que les organisations sans elle font bien.Voici comment exploiter ces nouvelles données pour améliorer les pratiques de gestion des risques d'application en 2024.
Comprendre l'état de la sécurité des logiciels 2024
Bien que le monde de la technologie évolue rapidement, une chose n'a pas changé: toute la sécurité des logiciels revient au code et aux vulnérabilités.De nouvelles solutions, comme le cloud-…
Insecure software is significantly impacting our world. In a recent statement, CISA Director Jen Easterly declared: “Features and speed to market have been prioritized against security, leaving our nation vulnerable to cyber invasion. That has to stop... We are at a critical juncture for our national security.” Our State of Software Security 2024 report explores a key area this trade-off of speed to market prioritized against security has resulted in: security debt. Our data shows that nearly half of organizations have persistent, high-severity flaws that constitute critical security debt. We also reveal what organizations without it are doing right. Here\'s how to leverage this new data to enhance application risk management practices in 2024. Understanding the State of Software Security 2024 Though the world of technology is rapidly evolving, one thing hasn\'t changed: all software security comes back to code and vulnerabilities. New solutions, like Cloud-… |
Vulnerability | ★★ | |
|
2024-02-26 15:17:44 | Étapes pratiques pour prévenir les vulnérabilités d'injection SQL Practical Steps to Prevent SQL Injection Vulnerabilities (lien direct) |
Dans le paysage numérique d'aujourd'hui, les applications Web et les API sont constamment menacées par des acteurs malveillants qui cherchent à exploiter les vulnérabilités.Une attaque commune et dangereuse est une injection SQL.
Dans ce blog, nous explorerons les vulnérabilités et les attaques de l'injection de SQL, comprendrons leur niveau de gravité et fournirons des étapes pratiques pour les empêcher.En mettant en œuvre ces meilleures pratiques, vous pouvez améliorer la sécurité de vos applications Web et API.
Comprendre les vulnérabilités et les attaques de l'injection SQL
Les attaques d'injection SQL se produisent lorsque les pirates manipulent les requêtes SQL d'une application \\ pour obtenir un accès non autorisé, altérer la base de données ou perturber la fonctionnalité de l'application \\.Ces attaques peuvent entraîner une usurpation d'identité, un accès aux données non autorisé et des attaques enchaînées.
L'injection SQL est une technique où les pirates injectent des requêtes SQL malveillantes dans la base de données backend d'une application Web.Cette vulnérabilité survient lorsque l'application accepte la saisie de l'utilisateur comme une instruction SQL que la base de données…
In today\'s digital landscape, web applications and APIs are constantly under threat from malicious actors looking to exploit vulnerabilities. A common and dangerous attack is a SQL injection. In this blog, we will explore SQL injection vulnerabilities and attacks, understand their severity levels, and provide practical steps to prevent them. By implementing these best practices, you can enhance the security of your web applications and APIs. Understanding SQL Injection Vulnerabilities and Attacks SQL injection attacks occur when hackers manipulate an application\'s SQL queries to gain unauthorized access, tamper with the database, or disrupt the application\'s functionality. These attacks can lead to identity spoofing, unauthorized data access, and chained attacks. SQL injection is a technique where hackers inject malicious SQL queries into a web application\'s backend database. This vulnerability arises when the application accepts user input as a SQL statement that the database… |
Vulnerability Threat Guideline Technical | ★★★ | |
|
2024-02-05 10:45:38 | Un guide de démarrage pour Veracode Dast Essentials A Getting Started Guide to Veracode DAST Essentials (lien direct) |
La critique du rôle des tests de sécurité des applications dynamiques (DAST)
Les applications Web sont l'un des vecteurs les plus courants pour les attaques, représentant plus de 40% des violations, selon le rapport de violation de données de Verizon \\.Les tests de sécurité des applications dynamiques (DAST) sont une technique cruciale utilisée par les équipes de développement et les professionnels de la sécurité pour sécuriser les applications Web dans le cycle de vie du développement logiciel.
En fait, le rapport sur l'état de la sécurité des logiciels de Veracode \\ révèle que 80% des applications Web ont des vulnérabilités critiques qui ne peuvent être trouvées qu'avec une solution de test de sécurité des applications dynamiques.Mais les pratiques de développement de logiciels modernes hiérarchisent les délais serrés.La demande est des versions plus rapides sans introduire de vulnérabilités, ce qui rend difficile pour les équipes de hiérarchiser la sécurité.Les tests de sécurité doivent fonctionner et évoluer dans la fréquence de votre vitesse et de libération de DevOps.
Début avec Veracode Dast Essentials
Veracode Dast Essentials est une application dynamique…
The Critical of Role of Dynamic Application Security Testing (DAST) Web applications are one of the most common vectors for attacks, accounting for over 40% of breaches, according to Verizon\'s Data Breach Report. Dynamic application security testing (DAST) is a crucial technique used by development teams and security professionals to secure web applications in the software development lifecycle. In fact, Veracode\'s State of Software Security Report reveals that 80% of web applications have critical vulnerabilities that can only be found with a dynamic application security testing solution. But modern software development practices prioritize tight deadlines. The demand is for faster releases without introducing vulnerabilities, making it difficult for teams to prioritize security. Security testing needs to work and scale within your DevOps speed and release frequency. Getting Started with Veracode DAST Essentials Veracode DAST Essentials is a dynamic application… |
Data Breach Vulnerability | ★★ | |
|
2024-01-22 05:10:56 | Outils de sécurité cloud essentiels pour les devsecops efficaces Essential Cloud Security Tools for Effective DevSecOps (lien direct) |
La mise en œuvre d'une approche DevSecops est le facteur clé le plus impactant dans le coût total d'une violation de données.Les DevseCops réussis dans un monde natif du cloud sont aidés par les bons outils.Voici une poignée des outils de sécurité du cloud les plus essentiels et ce qu'il faut rechercher pour aider DevseCops.
Top outil de sécurité du cloud essentiel pour DevSecops: analyse de composition logicielle
L'analyse de la composition logicielle (SCA) est le pain et le beurre des outils de sécurité du cloud pour des Devsecops efficaces et la sécurisation de la chaîne d'approvisionnement des logiciels.
Pourquoi cela compte: les logiciels open source (OSS) sont pratiques, mais il est livré avec quelques captures.Il y a des vulnérabilités, des mises à jour manquées et un risque de licence pour s'inquiéter.C'est là où SCA entre en jeu.
SCA adopte une approche proactive pour trouver ces risques tôt.Quelques choses que vous souhaitez rechercher lorsque vous choisissez le bon outil SCA pour vous:
Contrôle continu
Rapports et analyses avec référence par les pairs
Guide de remédiation et suggestions
Dépendance…
Implementation of a DevSecOps approach is the most impactful key factor in the total cost of a data breach. Successful DevSecOps in a cloud-native world is aided by the right tools. Here are a handful of the most essential cloud security tools and what to look for in them to aid DevSecOps. Top Essential Cloud Security Tool for DevSecOps: Software Composition Analysis Software Composition Analysis (SCA) is the bread and butter of cloud security tools for effective DevSecOps and securing the software supply chain. Why it matters: open-source software (OSS) is handy, but it comes with a few catches. There are vulnerabilities, missed updates, and license risk to be worried about. That\'s where SCA comes in. SCA takes a proactive approach to finding these risks early. A few things you want to look out for when picking the right SCA tool for you: Continuous Monitoring Reporting & Analytics with Peer Benchmarking Remediation Guidance & Fix Suggestions Dependency… |
Data Breach Tool Vulnerability Cloud | ★★★ | |
|
2024-01-08 09:39:09 | Sécuriser JavaScript: meilleures pratiques et vulnérabilités communes Securing JavaScript: Best Practices and Common Vulnerabilities (lien direct) |
JavaScript est le langage de programmation le plus utilisé, selon la plus récente enquête sur les développeurs Stackoverflow.Bien que JavaScript offre une grande flexibilité et une grande facilité d'utilisation, il présente également des risques de sécurité qui peuvent être exploités par les attaquants.Dans ce blog, nous explorerons les vulnérabilités en JavaScript, les meilleures pratiques pour sécuriser votre code et les outils pour empêcher les attaques.
Comprendre les vulnérabilités JavaScript
Cet article explore les vulnérabilités communes liées à la sécurité JavaScript et fournit les meilleures pratiques pour sécuriser votre code.
Si vous manquez de temps, vous pouvez commencer par utiliser Veracode Dast Essentials, un scanner de sécurité JavaScript, pour identifier les vulnérabilités potentielles.L'exécution de cet outil générera rapidement des rapports, mettra en évidence vos vulnérabilités spécifiques et fournira des instructions claires sur la façon de les résoudre.
Vulnérabilités de code source javascript
Les développeurs JavaScript s'appuient généralement sur l'intégration de nombreux packages et bibliothèques publiques ou open source contenant…
JavaScript is the most commonly-used programing language, according to the most recent StackOverflow developer survey. While JavaScript offers great flexibility and ease of use, it also introduces security risks that can be exploited by attackers. In this blog, we will explore vulnerabilities in JavaScript, best practices to secure your code, and tools to prevent attacks. Understanding JavaScript Vulnerabilities This article explores the common vulnerabilities related to JavaScript security and provides best practices to secure your code. If you\'re short on time, you can begin by using Veracode DAST Essentials, a JavaScript security scanner, to identify potential vulnerabilities. Running this tool will quickly generate reports, highlight your specific vulnerabilities, and provide clear instructions on how to remediate them. JavaScript Source Code Vulnerabilities JavaScript developers typically rely on integrating numerous public or open-source packages and libraries containing… |
Tool Vulnerability | ★★ | |
|
2024-01-04 13:35:17 | Que rechercher dans un scanner de vulnérabilité open source What To Look For in an Open Source Vulnerability Scanner (lien direct) |
L'une des principales préoccupations de sécurité que nous entendons des leaders de la technologie concerne la sécurité des logiciels open source (OSS) et le développement de logiciels cloud.Un scanner de vulnérabilité open source (pour la numérisation OSS) vous aide à découvrir le risque dans le code tiers que vous utilisez.Cependant, ce n'est pas parce qu'une solution scanne l'open source que vous réduisez finalement le risque de sécurité.Voici ce qu'il faut rechercher dans un scanner de vulnérabilité open source et une solution de test de sécurité pour trouver et corriger les vulnérabilités dans l'OSS.
Contexte sur les vulnérabilités en open source et à quoi ressemble le risque
Avant de pouvoir parler de ce qu'il faut rechercher dans une solution de numérisation, nous devons parler des vulnérabilités que les outils recherchent.Né en 1999, la base de données nationale de vulnérabilité (NVD) était un produit de l'Institut national des normes et de la technologie (NIST) conçu pour être «le référentiel du gouvernement américain des données de gestion de la vulnérabilité basées sur les normes».Il représente un indice des vulnérabilités connues…
One of the top security concerns we hear from technology leaders is about the security of open source software (OSS) and cloud software development. An open source vulnerability scanner (for scanning OSS) helps you discover risk in the third-party code you use. However, just because a solution scans open source does not mean you are ultimately reducing security risk with it. Here is what to look for in an open source vulnerability scanner and security testing solution to find and fix vulnerabilities in OSS. Background on Vulnerabilities in Open Source and What the Risk Looks Like Before we can talk about what to look for in a scanning solution, we need to talk about the vulnerabilities the tools are looking for. Born in 1999, the National Vulnerability Database (NVD) was a product of the National Institute of Standards and Technology (NIST) made to be “the U.S. government repository of standards based vulnerability management data.” It represents an index of known vulnerabilities… |
Tool Vulnerability Cloud | ★★★ | |
|
2023-12-14 12:07:06 | Ce que nos experts en sécurité ont discuté chez AWS RE: Invent 2023 What Our Security Experts Discussed at AWS re:Invent 2023 (lien direct) |
Le paysage du codage change alors que les développeurs adoptent l'IA, l'automatisation, les microservices et les bibliothèques tierces pour stimuler la productivité.Bien que chaque nouvelle approche améliore l'efficacité, comme une épée à double tranchant, les défauts et les vulnérabilités sont également introduits plus rapidement que les équipes ne peuvent les réparer.Découvrez l'une des dernières innovations qui résolvent cela dans un récapitulatif de ce que nos experts en sécurité ont discuté chez AWS RE: Invent 2023.
Veracode Fix: un changeur de jeu en régime pour les développeurs pour les développeurs
Au cours de leur segment AWS on Air, nos experts, vice-président de la gestion stratégique des produits, Tim Jarrett, et l'architecte des solutions seniors, Eric Kim, ont partagé comment Veracode Fix est un nouvel outil de changement de jeu qui aide les développeurs à réduire le processus de rétablissement des défauts depuis des moisà quelques minutes.
Tirant la puissance de l'IA, l'outil permet aux développeurs de réduire facilement les problèmes de sécurité en générant des correctifs suggérés pour le code existant qui est défectueux et vulnérable.
Alors que de nombreux outils de codage alimentés par l'IA sont conçus pour aider à écrire…
The landscape of coding is changing as developers embrace AI, automation, microservices, and third-party libraries to boost productivity. While each new approach enhances efficiency, like a double-edged sword, flaws and vulnerabilities are also introduced faster than teams can fix them. Learn about one of the latest innovations solving this in a recap of what our security experts discussed at AWS re:Invent 2023. Veracode Fix: A Game Changer in Flaw Remediation for Developers During their AWS on Air segment, our experts, Vice President of Strategic Product Management, Tim Jarrett, and Senior Solutions Architect, Eric Kim, shared how Veracode Fix is a new game-changing tool that helps developers cut down the flaw remediation process from months to minutes. Leveraging the power of AI, the tool allows developers to easily reduce security issues by generating suggested fixes for existing code that is flawed and vulnerable. While many AI-powered coding tools are designed to help write… |
Tool Vulnerability | ★★★ | |
|
2023-12-07 13:23:31 | État des vulnérabilités log4j: combien Log4Shell a-t-il changé? State of Log4j Vulnerabilities: How Much Did Log4Shell Change? (lien direct) |
Le 9 décembre, deux ans depuis que le monde a été très alerte en raison de ce qui a été considéré comme l'une des vulnérabilités les plus critiques de tous les temps: log4shell.La vulnérabilité qui a porté la cote de gravité la plus élevée possible (10,0) était dans Apache Log4J, un cadre de journalisation Java omniprésent que Veracode a estimé à l'époque a été utilisé dans 88% des organisations.
Si exploité, la vulnérabilité du jour zéro (CVE-2021-44228) dans les versions log4j log4j2 2.0-beta9 à 2.15.0 (excluant les versions de sécurité 2.12.2, 2.12.3 et 2.3.1) permettrait aux attaquants une télécommande une télécommande 2.12.2, 2.12.3 et 2.3.1) permettrait aux attaquants une télécommande une distance à distanceExécution de code (RCE) Attaquez et compromettez le serveur affecté.
Il a déclenché un effort massif pour corriger les systèmes affectés, estimés à des centaines de millions.L'apocalypse que beaucoup craignait ne se produisait pas, mais compte tenu de son omniprésence, le comité d'examen du cyber-sécurité du département américain de la sécurité intérieure \\ a déterminé que la correction de Log4Shell prendrait une décennie.
L'anniversaire de deux ans de Log4Shell est un bon…
December 9 marks two years since the world went on high alert because of what was deemed one of the most critical zero-day vulnerabilities ever: Log4Shell. The vulnerability that carried the highest possible severity rating (10.0) was in Apache Log4j, an ubiquitous Java logging framework that Veracode estimated at the time was used in 88 percent of organizations. If exploited, the zero-day vulnerability (CVE-2021-44228) in Log4j versions Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) would allow attackers to perform a remote code execution (RCE) attack and compromise the affected server. It triggered a massive effort to patch affected systems, estimated to be in the hundreds of millions. The apocalypse that many feared didn\'t happen, but given its pervasiveness, the U.S. Department of Homeland Security\'s Cyber Safety Review Board determined that fully remediating Log4Shell would take a decade. The two-year anniversary of Log4Shell is a good… |
Vulnerability Threat | ★★ | |
|
2023-12-04 12:06:25 | Recommandations de gestion de la vulnérabilité open source pour 2024 Open Source Vulnerability Management Recommendations for 2024 (lien direct) |
En marchant en 2024, la dynamique de la gestion de la vulnérabilité open source change.Des changements rapides au développement de logiciels exigent une approche plus nuancée de la sécurité open source des praticiens.De la redéfinition du risque à l'intégration prudente de la rééducation automatique, voici les recommandations pivots pour une gestion réussie de la vulnérabilité open source en 2024 et au-delà.
1. Embrassez la permanence des vulnérabilités open source (et it \\)
Nous le connaissons depuis des années;L'Open Source est là pour rester.Le rapport OctOverOverse de GitHub \\ nous indique: «Un énorme 97% des applications exploitent le code open-source, et 90% des entreprises postulent ou l'utilisent d'une manière ou d'une autre.»
La permanence (et le risque) de l'open source est prouvée par le décret exécutif de la Maison Blanche sur l'amélioration de la cybersécurité de la nation.Il accorde une énorme importance à la gestion de la vulnérabilité open source, l'appelant spécifiquement: «Les développeurs utilisent souvent des composants logiciels open source et tiers disponibles pour créer un produit ...…
Stepping in 2024, the dynamics of open source vulnerability management are shifting. Rapid changes to software development demand a more nuanced approach to open source security from practitioners. From redefining risk to the cautious integration of auto-remediation, here are the pivotal recommendations for successful open source vulnerability management in 2024 and beyond. 1. Embrace the Permanence of Open Source (& It\'s Vulnerabilities) We\'ve known it for years; open source is here to stay. Github\'s Octoverse report tells us: “A whopping 97% of applications leverage open-source code, and 90% of companies are applying or using it in some way.” The permanence (and risk) of open source is proven by the White House\'s Executive Order on Improving the Nation\'s Cybersecurity. It places huge importance on open source vulnerability management, calling it out specifically: “Developers often use available open source and third-party software components to create a product...… |
Vulnerability | ★★★ | |
|
2023-12-01 13:50:00 | Empêcher les vulnérabilités de contrôle d'accès brisé dans les applications Web Preventing Broken Access Control Vulnerabilities in Web Applications (lien direct) |
Comprendre le contrôle d'accès brisé
Le contrôle d'accès est crucial pour le développement Web moderne car il permet à la gestion de la façon dont les utilisateurs, les processus et les appareils devraient se voir accorder des autorisations aux fonctions et aux ressources d'application.Les mécanismes de contrôle d'accès déterminent également le niveau d'accès autorisé et manifeste les activités menées par des entités spécifiques.Les vulnérabilités de contrôle d'accès cassé surviennent lorsqu'un utilisateur malveillant abuse des contraintes sur les actions qu'ils sont autorisés à effectuer ou les objets auxquels ils peuvent accéder.Les attaquants exploitent généralement les défaillances du contrôle d'accès pour obtenir un accès non autorisé aux ressources dans l'application Web, exécuter des commandes malveillantes ou obtenir une autorisation de l'utilisateur privilégié.
Ce blog traite des vulnérabilités de contrôle d'accès cassées et des techniques de prévention courantes pour mieux sécuriser vos applications Web.
Les problèmes de contrôle d'accès permettent aux utilisateurs non autorisés d'accéder, de modifier et de supprimer des ressources ou d'effectuer des actions qui dépassent leurs autorisations prévues.Accès cassé…
Understanding Broken Access Control Access control is crucial for modern web development as it enables the management of how users, processes, and devices should be granted permissions to application functions and resources. Access control mechanisms also determine the level of access permitted and manifest activities carried out by specific entities. Broken access control vulnerabilities arise when a malicious user abuses the constraints on the actions they are allowed to perform or the objects they can access. Attackers typically leverage access control failures to gain unauthorized access to resources within the web application, run malicious commands, or gain a privileged user\'s permission. This blog discusses broken access control vulnerabilities and common prevention techniques to better secure your web applications. Access control issues enable unauthorized users to access, modify, and delete resources or perform actions that exceed their intended permissions. Broken access… |
Vulnerability | ★★ | |
|
2023-11-27 16:01:16 | Top 5 des risques de sécurité open source Les dirigeants informatiques doivent connaître Top 5 Open Source Security Risks IT Leaders Must Know (lien direct) |
Se cacher dans les logiciels open source (OSS) qui imprègnent les applications du monde entier sont des risques de sécurité open source Les leaders de la technologie doivent être conscients.Le logiciel est l'un des sous-ensembles les plus vulnérables de la technologie avec plus de 70% des applications contenant des défauts de sécurité.Voici les risques de sécurité open source Les leaders informatiques doivent être conscients de protéger la technologie et de l'aider à évoluer en toute sécurité.
Pourquoi aborder les risques de sécurité des logiciels open source
Le 9 décembre 2021, un tweet a exposé une vulnérabilité dans la bibliothèque OSS largement utilisée Log4J.Il ne fallait pas longtemps avant que les attaquants du monde entier ne travaillent pour exploiter la vulnérabilité log4j.Cet incident a été un signal d'alarme à la façon dont la sécurité d'une bibliothèque peut changer rapidement et des mesures proactives doivent être en place pour se protéger de ce danger.
Log4j n'est qu'un exemple de la façon dont les vulnérabilités de l'open source posent des risques importants qui peuvent avoir un impact sur les opérations, la sécurité des données et la santé informatique globale.Les choix technologiques stratégiques peuvent avoir un impact important sur la quantité…
Lurking in the open source software (OSS) that pervades applications around the world are open source security risks technology leaders must be aware of. Software is one of technology\'s most vulnerable subsets with over 70% of applications containing security flaws. Here are the open source security risks IT leaders must be aware of to protect technology and help it scale safely. Why Address Open Source Software Security Risks On December 9, 2021, a Tweet exposed a vulnerability in the widely-used OSS library Log4j. It didn\'t take long before attackers around the world were working to exploit the Log4j vulnerability. This incident was a wake-up call to how the security of a library can quickly change and proactive measures must be in place to protect from this danger. Log4j is just one example of how vulnerabilities in open source pose significant risks that can impact operations, data security, and overall IT health. Strategic technology choices can make a big impact on how much… |
Vulnerability Threat | ★★ | |
|
2023-11-12 22:55:15 | Sécuriser vos applications Web et vos API avec Veracode Dast Essentials Securing Your Web Applications and APIs with Veracode DAST Essentials (lien direct) |
Les applications Web sont l'un des vecteurs les plus courants pour les violations, représentant plus de 40% des violations selon le rapport de violation de données de Verizon \'s 2022.S'assurer que vos applications Web sont suffisamment protégées et continuent d'être surveillées une fois qu'elles sont en production est essentielle à la sécurité de vos clients et de votre organisation.
Rester en avance sur la menace
Les attaquants recherchent constamment de nouvelles façons d'exploiter les vulnérabilités et de violer les applications Web, ce qui signifie que à mesure que leurs méthodes mûrissent et deviennent plus agressives, même les applications les plus développées peuvent devenir vulnérables.Les organisations qui effectuent uniquement des tests de pénétration annuelle sur leurs applications Web peuvent se laisser ouvertes à une violation qui pourrait être facilement empêchée par une analyse de production régulière.
La sécurité des applications décrit une collection de processus et d'outils axés sur l'identification, la correction et la prévention des vulnérabilités au niveau des applications tout au long du développement logiciel…
Web applications are one of the most common vector for breaches, accounting for over 40% of breaches according to Verizon\'s 2022 Data Breach Report. Ensuring that your web applications are sufficiently protected and continue to be monitored once they are in production is vital to the security of your customers and your organization. Staying Ahead of the Threat Attackers are constantly looking for new ways to exploit vulnerabilities and to breach web applications, which means that as their methods mature and they become more aggressive, even the most securely developed applications can become vulnerable. Organizations that only perform annual penetration tests on their web applications may be leaving themselves open to a breach that could be easily prevented with regular production scanning. Application security outlines a collection of processes and tools focused on identifying, remediating, and preventing application-level vulnerabilities throughout the entire software development… |
Data Breach Tool Vulnerability Threat | ★★ | |
|
2023-11-02 13:45:06 | SAST vs. DAST for Security Testing: Unveiling the Differences (lien direct) | Les tests de sécurité des applications (AST) comprennent divers outils, processus et approches pour scanner des applications pour découvrir des problèmes de sécurité potentiels.Les tests de sécurité des applications statiques (SAST) et les tests de sécurité des applications dynamiques (DAST) sont des approches de test de sécurité populairement utilisées qui suivent différentes méthodologies de codes d'application de numérisation à différentes étapes d'un cycle de vie de développement logiciel.
Sast suit une approche de test de boîte blanche pour analyser le code source, le code d'octets et les binaires pour identifier les vulnérabilités exploitables et les erreurs de codage.D'un autre côté, DAST met en œuvre une méthode de test de la boîte noire, où les ingénieurs de sécurité analysent les charges utiles simulées d'attaque via le frontal de l'application sans exposer des informations internes sur la construction interne de l'application \\.
Dans ce blog, nous discuterons des approches de tests de Sast et de Dast, comment ils aident à détecter les vulnérabilités et les défaillances des applications, leurs différences et les meilleurs cas d'utilisation.
Application statique…
Application Security Testing (AST) encompasses various tools, processes, and approaches to scanning applications to uncover potential security issues. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are popularly used security testing approaches that follow different methodologies of scanning application codes across different stages of a software development lifecycle. SAST follows a white-box testing approach to analyze the source code, byte code, and binaries to identify exploitable vulnerabilities and coding errors. On the other hand, DAST implements a black-box testing method, where security engineers parse simulated attack payloads through the application\'s front end without exposing internal information on the application\'s internal construct. In this blog, we will discuss SAST and DAST testing approaches, how they help detect vulnerabilities and application failures, their differences, and best use cases. Static Application… |
Tool Vulnerability | ★★ | |
|
2023-10-02 11:06:07 | Un CISO explique 4 étapes qui facilitent la séjour en sécurité en ligne A CISO Explains 4 Steps that Make it Easy to Stay Safe Online (lien direct) |
Pour sécuriser notre monde, le Mois de sensibilisation à la cybersécurité encourage quatre étapes qui facilitent la séjour en sécurité en ligne.En tant que CISO, mon équipe et moi défendons constamment ces pratiques au sein de notre organisation.Si vous êtes un praticien de la sécurité qui cherche à renforcer la sensibilisation à la cybersécurité, voici un bref aperçu de la façon dont nous expliquons ces étapes pour faciliter la sécurité en ligne.
Avant de plonger, rendre les pratiques de cybersécurité relatables et claires est la clé de l'adoption dans toute organisation.Considérez la divulgation récente d'une nouvelle vulnérabilité affectant les applications Web.Il s'agit du type de scénario réel qui peut être utilisé pour rendre les informations suivantes plus relatables.De nouvelles vulnérabilités comme celle-ci sont ce qui rend le premier pas si important.
Mises à jour logicielles & # 8211;Le pourquoi et comment
Les mises à jour logicielles sont essentielles pour garder votre ordinateur sécurisé et à jour.Ils peuvent corriger les bogues, améliorer les performances, ajouter de nouvelles fonctionnalités et rendre votre logiciel compatible avec de nouveaux matériels et logiciels.…
To secure our world, Cybersecurity Awareness Month encourages four steps that make it easy to stay safe online. As a CISO, my team and I advocate for these practices constantly within our organization. If you are a security practitioner looking to bolster cybersecurity awareness, here\'s a brief look at how we explain these steps to help make staying safe online easier. Before we dive in, making cybersecurity practices relatable and clear is key to the adoption at any organization. Consider the recent disclosure of a new vulnerability affecting web applications. This is the type of real-life scenario that can be used to make the following information more relatable. New vulnerabilities like this one are what makes the first step so important. Software Updates – The Why & How Software updates are essential for keeping your computer secure and up-to-date. They can fix bugs, improve performance, add new features, and make your software compatible with new hardware and software. … |
Vulnerability | ★★ | |
|
2023-09-29 10:12:09 | Résolution de la vulnérabilité webp-jour CVE-2023-4863 Resolving WebP Zero-day Vulnerability CVE-2023-4863 (lien direct) |
Ce que c'est
WebP est l'épine dorsale de l'extension webp.Toute image enregistrée au format d'image WebP a probablement été créée à l'aide de la bibliothèque WebP.La bibliothèque a été publiée en 2010 par Google.
L'histoire de la vulnérabilité Webp CVE-2023-4863
Le premier CVE pour cette vulnérabilité WebP a été divulgué dans CVE-2023-41061, mais notez comment la description ne mentionne la racine du problème nulle part.Ensuite, Google a publié CVE-2023-4863, qui a été la première mention réelle de WebP.Enfin, CVE-2023-5129 a été libéré, mais a depuis été rejeté.La description originale du CVE-2023-5129 était:
«Avec un fichier WebP sans perte spécialement conçu, LibWebp peut écrire des données hors des limites au tas.La fonction ReadHuffMancodes () alloue le tampon HuffMancode avec une taille qui provient d'un tableau de tailles précomputées: KTABLIZE.La valeur Color_Cache_Bits définit la taille à utiliser.Le tableau KtableSize ne prend en compte que les tailles pour les recherches de table de premier niveau à 8 bits mais pas la table de deuxième niveau…
What It Is Webp is the backbone of the webp extension. Any image that is saved to the webp image format most likely was created using the webp library. The library was released in 2010 by Google. The History of the Webp Vulnerability CVE-2023-4863 The first CVE for this webp vulnerability was disclosed in CVE-2023-41061, but note how the description does not mention the root of the issue anywhere. Then Google released CVE-2023-4863, which was the first actual mention of webp. Finally CVE-2023-5129 was released, but has since been rejected. The original description of CVE-2023-5129 was: “With a specially crafted WebP lossless file, libwebp may write data out of bounds to the heap. The ReadHuffmanCodes() function allocates the HuffmanCode buffer with a size that comes from an array of precomputed sizes: kTableSize. The color_cache_bits value defines which size to use. The kTableSize array only takes into account sizes for 8-bit first-level table lookups but not second-level table… |
Vulnerability | ★★ | |
|
2023-07-20 11:35:59 | SBOM a expliqué: comment SBOMS améliore la sécurité des applications natives dans le cloud SBOM Explained: How SBOMs Improve Cloud-native Application Security (lien direct) |
Un stupéfiant 96% des organisations utilisent des bibliothèques open source, mais moins de 50% gèrent activement les vulnérabilités de sécurité au sein de ces bibliothèques.Les vulnérabilités sont les bienvenus pour violations des mauvais acteurs, et une fois qu'ils ont entré votre système, l'impact peut être colossal.Une facture de matériel logiciel (SBOM) est un outil important pour gérer la sécurité des logiciels open source.Ici, nous explorerons comment les SBOMS aident les organisations à comprendre ce qui est dans leurs applications, à garantir la conformité réglementaire et à gérer le risque global.
Où les SBOM s'inscrivent-ils dans le programme de sécurité de votre application?
Considérez un SBOM comme une loupe qui vous permet de voir de plus près ce qui se passe dans vos applications natives dans le cloud.Les SBOMS fournissent une vue détaillée des composants open source que les développeurs et les professionnels de la sécurité peuvent utiliser pour comprendre la sécurité des bibliothèques et des dépendances tierces utilisées dans une application.Avec ces informations, les équipes peuvent créer des campagnes de cyber-hygiène contre connu…
A staggering 96% of organizations utilize open-source libraries, yet fewer than 50% actively manage the security vulnerabilities within these libraries. Vulnerabilities are welcome mats for breaches from bad actors, and once they\'ve entered your system, the impact can be colossal. A software bill of materials (SBOM) is an important tool for managing the security of open-source software. Here we will explore how SBOMs help organizations understand what\'s in their applications, ensure regulatory compliance, and manage overall risk. Where Do SBOMs Fit in Your Application Security Program? Think of an SBOM as a magnifying glass that allows you to get a closer look at what goes on in your cloud-native applications. SBOMs provide a detailed view of open-source components that developers and security professionals can use to understand the security of third-party libraries and dependencies used in an application. With that information, teams can create cyber hygiene campaigns against known… |
Tool Vulnerability | ★★★ | |
|
2023-07-10 12:57:59 | Comment décider si la vulnérabilité a augmenté How to Decide Whether Vulnerability Remediation Augmented by Generative AI Reduces or Incurs Risk (lien direct) |
Les fournisseurs de sécurité logicielle appliquent une IA générative aux systèmes qui suggèrent ou appliquent des corrections pour les vulnérabilités logicielles.Cette technologie offre aux équipes de sécurité les premières options réalistes pour gérer la dette de sécurité à grande échelle tout en montrant aux développeurs l'avenir qui leur avait été promis;où le travail vise à créer une valeur utilisateur au lieu de faire boucler à un ancien code qui génère de nouveaux travaux.Cependant, il y a certaines préoccupations concernant les risques d'utilisation de l'IA génératrice pour augmenter l'assainissement de la vulnérabilité.Laissez \\ explorer ce paysage en évolution rapide et comment vous pouvez récolter les avantages sans encourir les risques.
Ce qui risque de générer des solutions de remédiation de vulnérabilité augmentée en AI pourrait poser
Les défis juridiques à l'approvisionnement des données exposent le risque de formation des modèles d'IA génératifs sur tous les code.Malheureusement, cela n'a pas empêché de nombreux fournisseurs de prendre la position qu'un modèle formé sur le code open-source est suffisamment à l'abri des problèmes de provenance de l'IP et du code.
Tout le code n'est pas également…
Software security vendors are applying Generative AI to systems that suggest or apply remediations for software vulnerabilities. This tech is giving security teams the first realistic options for managing security debt at scale while showing developers the future they were promised; where work is targeted at creating user value instead of looping back to old code that generates new work. However, there are certain concerns with the risks of utilizing Generative AI for augmenting vulnerability remediation. Let\'s explore this rapidly evolving landscape and how you can reap the benefits without incurring the risks. What Risks Generative AI Augmented Vulnerability Remediation Solutions Could Pose Legal challenges to data sourcing expose the risk of training Generative AI models on all code. Unfortunately, that hasn\'t stopped many vendors from taking the position that a model trained on open-source code is sufficiently safe from IP and code provenance concerns. Not all code is equally… |
Vulnerability | ★★ | |
|
2023-06-07 16:19:57 | 3 raisons de tirer parti de l'IA pour une gestion améliorée des menaces et de la vulnérabilité 3 Reasons to Leverage AI for Enhanced Threat and Vulnerability Management (lien direct) |
Alors que le paysage cyber-menace continue d'évoluer, vous savez qu'il y a un besoin croissant de s'assurer que les applications et les logiciels sont protégés contre les acteurs malveillants.Une approche holistique et intelligente de la gestion des menaces et de la vulnérabilité est essentielle pour assurer la sécurité contre la cyber-risque moderne.En tirant parti des outils alimentés par l'IA, en particulier pour les tâches telles que les défauts de sécurité, vous pouvez gérer et réduire les risques rapidement et efficacement.Laissez \\ explorer pourquoi l'utilisation de l'IA pour renforcer et moderniser vos stratégies de gestion de la menace et de la vulnérabilité remboursera beaucoup de temps à long terme.
Raison 1: pour rester en avance sur les menaces de cybersécurité en évolution rapide
La gestion des menaces et de la vulnérabilité aide les entreprises à comprendre et à répondre aux risques, mais qu'en est-il du moment où le paysage des menaces évolue si rapidement?Lorsque de nouvelles menaces émergent constamment, il est difficile de adopter une approche préventive des attaques potentielles dans les applications, les logiciels et les réseaux.
Par exemple, une nouvelle tendance particulièrement concernant la nouvelle tendance est…
As the cyber threat landscape continues to evolve, you know there\'s a growing need to ensure applications and software are protected from malicious actors. A holistic and intelligent approach to threat and vulnerability management is essential for ensuring security against modern cyber risk. By leveraging AI-powered tools, especially for tasks like remediating security flaws, you can manage and reduce risk quickly and effectively. Let\'s explore why using AI to bolster and modernize your threat and vulnerability management strategies will pay off big time in the long run. Reason 1: To Stay Ahead of Rapidly Evolving Cybersecurity Threats Threat and vulnerability management helps businesses understand and respond to risk, but what about when the threat landscape is evolving so rapidly? When new threats emerge constantly, it\'s challenging to take a preventative approach to potential attacks in applications, software, and networks. For example, one particularly concerning new trend is… |
Vulnerability Threat Prediction | ★★ | |
|
2023-05-27 10:43:28 | Sécuriser la chaîne d'approvisionnement des logiciels: protéger contre les téléchargements de code insécurité Securing the Software Supply Chain: Protecting Against Insecure Code Downloads (lien direct) |
Introduction
Dans le monde interconnecté d'aujourd'hui, la sécurisation de la chaîne d'approvisionnement des logiciels est cruciale pour maintenir une sécurité des applications robuste.Les développeurs comptent souvent sur les gestionnaires de packages pour importer des code et des bibliothèques tiers, mais cette commodité comporte des risques.Les téléchargements de code insécurité peuvent introduire des vulnérabilités qui compromettent l'intégrité de votre logiciel.
Dans ce billet de blog, nous explorerons les étapes essentielles pour sécuriser la chaîne d'approvisionnement et empêcher les développeurs de télécharger du code insécurité à partir des gestionnaires de packages.
Sécurité du gestionnaire de package: Commencez par l'utilisation d'un gestionnaire de packages réputé qui hiérarte la sécurité.Les gestionnaires de packages populaires comme NPM, PYPI et Maven ont des fonctionnalités de sécurité intégrées, y compris la signature de package, la numérisation de vulnérabilité et le suivi de la dépendance.Ces mesures aident à garantir que les packages que vous téléchargez proviennent de sources de confiance.
Audit et test de code: implémentez un processus d'audit et de test de code rigoureux pour identifier les vulnérabilités dans votre base de code.Régulièrement…
Introduction In today\'s interconnected world, securing the software supply chain is crucial for maintaining robust application security. Developers often rely on package managers to import third-party code and libraries, but this convenience comes with risks. Insecure code downloads can introduce vulnerabilities that compromise the integrity of your software. In this blog post, we will explore essential steps to secure the supply chain and prevent developers from downloading insecure code from package managers. Package Manager Security: Start by using a reputable package manager that prioritizes security. Popular package managers like npm, PyPI, and Maven have built-in security features, including package signing, vulnerability scanning, and dependency tracking. These measures help ensure the packages you download are from trusted sources. Code Auditing and Testing: Implement a rigorous code auditing and testing process to identify vulnerabilities within your codebase. Regularly… |
Vulnerability | ★★ | |
|
2023-05-18 11:24:49 | 25 ans plus tard: Réfléchir le témoignage du Congrès de L0pht \\ de 1998 et l'évolution de la cybersécurité 25 Years Later: Reflecting on L0pht\\'s 1998 Congress Testimonial and the Evolution of Cybersecurity (lien direct) |
Je reviens sur le témoignage de L0PHT \\ avant le Congrès en 1998 avec un mélange de fierté et de réflexion.Cela fait vingt-cinq ans depuis que notre groupe de pirates (ou chercheurs en vulnérabilité, si vous voulez) s'est intensifié pour sensibiliser à l'importance de la sécurité Internet devant certains des législateurs les plus puissants du monde.Cet événement a marqué le début d'un long voyage vers l'augmentation de la sensibilisation à la cybersécurité et de la mise en œuvre de mesures pour protéger notre monde numérique.Laissez \\ jeter un coup d'œil à jusqu'où nous venons et ce qui doit encore être fait.
La brûlure lente: du témoignage de L0pht \\ à l'action gouvernementale
Le témoignage de 1998 de L0PHT \\ a préparé le terrain pour les 25 prochaines années de sensibilisation à la sécurité Internet.Cependant, il a fallu des années au changement pour commencer à se produire.Même mon témoignage de 2003 au Congrès a toujours prouvé que nous avons un long chemin à parcourir dans la construction de logiciels sécurisés.Les roues du progrès ont commencé à tourner lorsque certaines recommandations du rapport de la Commission de la Solarium 2020 ont été mises en œuvre, appelant le…
I look back on L0pht\'s testimony before Congress in 1998 with a mix of pride and reflection. It\'s been twenty-five years since our group of hackers (or vulnerability researchers, if you will) stepped up to raise awareness about the importance of internet security in front of some of the world\'s most powerful lawmakers. This event marked the beginning of a long journey towards increased cybersecurity awareness and implementation of measures to protect our digital world. Let\'s take a look at how far we\'ve come and what still needs to be done. The Slow Burn: From L0pht\'s Testimony to Government Action L0pht\'s 1998 testimony set the stage for the next 25 years of internet security awareness. However, it took years for change to start happening. Even my 2003 testimony to Congress still proved that we have a long way to go in building secure software. The wheels of progress began to turn when some recommendations from the 2020 Solarium Commission Report were implemented, calling for the… |
Vulnerability | ★★ | |
|
2023-05-09 09:12:11 | Une introduction au codage sécurisé avec des moteurs de modèle An Introduction to Secure Coding with Template Engines (lien direct) |
En 2022, tout en parcourant des listes de vulnérabilités récemment divulguées, je suis tombé sur certaines vulnérabilités open source d'Adobe Commerce / Magento [1], qui auraient été exploitées dans la nature et peuvent être exploitées pour atteindre l'exécution du code distant, une combinaison qui toujoursme motive à jeter un coup d'œil à la vulnérabilité.Adobe a fourni un fichier de correctif simple qui supprime efficacement les caractères {{et}} lorsqu'il est rencontré dans l'entrée fournie à deux composants spécifiques et il est raisonnable de supposer que la vulnérabilité implique le système de templation intégré de Magento \\.
Bien que Magento utilise son propre système de modèles personnalisé, ces vulnérabilités m'ont fait réfléchir aux défis généraux auxquels les développeurs sont confrontés lorsqu'ils essaient de s'assurer qu'ils utilisent un moteur de modèle d'une manière qui n'introduisait pas de défauts de sécurité.Après avoir parcouru les montagnes de la documentation et même la plongeon dans le code de certains des moteurs de modèle les plus populaires, il est devenu très clair que la quantité de travail…
Back in 2022 while browsing through lists of recently disclosed vulnerabilities, I happened upon some Adobe Commerce/Magento Open Source vulnerabilities [1], that were reported to be exploited in the wild and can be exploited to achieve remote code execution, a combination which always motivates me to take a quick look at the vulnerability. Adobe provided a simple patch file that effectively removes {{ and }} characters when encountered in input provided to two specific components and it is reasonable to assume that the vulnerability involves Magento\'s built-in templating system. Although Magento uses its own custom templating system, these vulnerabilities got me thinking about the general challenges developers face when trying to ensure they are using a template engine in a way that does not introduce security flaws. After looking through mountains of documentation and even diving into the code of some of the most popular template engines, it became very clear that the amount of work… |
Vulnerability | ★★ | |
|
2023-03-03 11:03:14 | Resolving CVE-2022-1471 with the SnakeYAML 2.0 Release (lien direct) | In October of 2022, a critical flaw was found in the SnakeYAML package, which allowed an attacker to benefit from remote code execution by sending malicious YAML content and this content being deserialized by the constructor. Finally, in February 2023, the SnakeYAML 2.0 release was pushed that resolves this flaw, also referred to as CVE-2022-1471. Let's break down how this version can help you resolve this critical flaw. Exploring Deserialization SnakeYAML is a popular Java library to parse YAML (YAML Ain't Markup Language format). The library can parse all YAML 1.1 specifications [1], native types [2] and supports serializing and deserializing Java objects. The Remote Code Execution vulnerability is due to the library not restricting Java types when deserializing objects using `Constructor`. Java Serialization has the great promise of taking the state of a full object graph and saving it externally, then magically restoring its state when we deserialize. This is a big promise as… | Vulnerability | ★★ | |
|
2022-12-07 13:15:44 | What We\'ve Learned About Reducing Open-source Risk Since Log4j (lien direct) | I share a birthday with the Log4j event. However, unlike this event, I've been around for more than one year. On December 9th, 2021, a Tweet exposed a zero-day vulnerability in Log4j, a widely-used piece of open-source software. The announcement made headlines everywhere, and cybersecurity was suddenly put in the spotlight. It was a wake-up call for many because, in an instant, software that had been considered secure was suddenly at tremendous risk. Looking back over the aftermath of the past year, here's what Log4j has taught us about reducing open-source risk. What Log4j Has Revealed About the Risk of Open-source Libraries With a CVSS severity level of 10 out of 10, the urgent response to Log4j was warranted. Upon the announcement, we quickly discovered that 58 percent of enterprises were using the vulnerable version of Log4j, and Microsoft shared shortly after the announcement that state-backed hackers around the world had already tried to exploit the Log4j vulnerability. How… | Vulnerability | ★★ | |
|
2022-11-18 15:03:25 | Anatomy of a Stored Cross-site Scripting Vulnerability in Apache Spark (lien direct) | One of the services that Veracode offers is a consultation with an Application Security Consultant – a seasoned software developer and application security expert. In the context of a consultation, my team works with the software engineers of Veracode's customers to understand and, ideally, remediate security flaws found by the Veracode tool suite. There is a well-defined difference between a security flaw (a defect that can lead to a vulnerability) and a vulnerability (an exploitable condition within code that allows an attacker to attack it). While working with potentially dozens of different customer applications every week, we usually have a strong gut feeling for when a security flaw might constitute an exploitable vulnerability and should receive extra attention. During one of our consultations, a set of similar Cross-site Scripting (XSS) flaws was discovered by Veracode Static Analysis in what turned out to be 3rd party JavaScript files belonging to Apache Spark. After some… | Tool Vulnerability Guideline | ||
|
2022-11-01 10:23:26 | What You Need to Know About OpenSSL-3.0.7 (lien direct) | OpenSSL released version 3.0.7 with security fixes for High Severity vulnerabilities CVE-2022-3786 & CVE-2022-3602 discussed here. Here's how to know if you're affected and what to do if you are. Am I affected? At this moment it seems that OpenSSL versions between 3.0.0 and 3.0.6 and applications using the OpenSSL library within the affected versions are vulnerable. OpenSSL 3.x was released just about one year ago: OpenSSL 3.0 Has Been Released! - OpenSSL Blog; container images, distributions and software released before this date are unlikely to be affected. OpenSSL can be installed through a package manager that install it in well-known locations and configure it at system level, or it can be downloaded on the system as a compiled binary or even compiled locally from source code. These different approaches don't allow to list all possible ways to detect the versions of OpenSSL installed on the system. LibreSSL is not affected by this vulnerability (oss-security - Re:… | Vulnerability | ||
|
2022-09-19 17:40:15 | Analysis and Remediation Guidance of CSRF Vulnerability in Csurf Express.js Middleware (lien direct) | Technical Summary On 28th of August fortbridge.co.uk reported a vulnerability in csurf middleware – expressjs supporting library that enables CSRF protection in expressjs. As of 13th of September csurf library has been deprecated with no plans to fix the vulnerabilities. There is no viable alternative for csurf middleware now. Am I Affected? All versions of csurf library are vulnerable if: csurf is setup to use double-submit cookies – csurf({cookie: true}) and default value function is in use Setting up cookie signatures as described here: https://www.npmjs.com/package/csurf#cookie does not prevent the bypass Indicators of an Attack Reliable indicator of attampted exploitation would include either: request query variable _csrf with a value request body variable _csrf with a value This is assuming the default value function is in use as described here: https://www.npmjs.com/package/csurf#value If verbose access logs are enabled there's another indicator that may be useful. In… | Vulnerability | ||
|
2022-05-11 19:08:48 | (Déjà vu) What Is Software Supply Chain Security? (lien direct) | Most software today isn't developed entirely from scratch. Instead, developers rely on a range of third-party resources to create their applications. By using pre-built libraries, developers don't need to reinvent the wheel. They can use what already exists and spend time on proprietary code, helping to differentiate their software, finish projects quicker, reduce costs, and stay competitive. These third-party libraries make up part of the software supply chain. While their inclusion is beneficial, the software supply chain introduces risk and needs to be secured. Significant breaches in recent times suggest that software supply chain attacks are on the rise. Reading about the Log4j vulnerability or the SolarWinds supply chain attack reminds us that software components can be security threats. Since these types of attacks are relatively new, most organizations often struggle to determine how their applications might be affected and how they should address the threat. Effective… | Vulnerability | ||
|
2022-05-11 19:08:48 | What Is Software Supply Chain Security? (lien direct) | Most software today isn't developed entirely from scratch. Instead, developers rely on a range of third-party resources to create their applications. By using pre-built libraries, developers don't need to reinvent the wheel. They can use what already exists and spend time on proprietary code, helping to differentiate their software, finish projects quicker, reduce costs, and stay competitive. These third-party libraries make up part of the software supply chain. While their inclusion is beneficial, the software supply chain introduces risk and needs to be secured. Significant breaches in recent times suggest that software supply chain attacks are on the rise. Reading about the Log4j vulnerability or the SolarWinds supply chain attack reminds us that software components can be security threats. Since these types of attacks are relatively new, most organizations often struggle to determine how their applications might be affected and how they should address the threat. Effective… | Vulnerability | ★★ | |
|
2022-04-20 18:35:10 | Just Because You Don\'t Use Log4j or Spring Beans Doesn\'t Mean Your Application is Unaffected (lien direct) | By now, you're probably all aware of the recent Log4j and Spring Framework vulnerabilities. As a recap, the Log4j vulnerability – made public on December 10, 2021 – was the result of an exploitable logging feature that, if successfully exploited, could allow attackers to perform an RCE (Remote Code Execution) and compromise the affected server. The Spring Framework vulnerability – made public on March 29, 2021 – was caused by unforeseen access to Tomcat's ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server. Just because your organization isn't using a vulnerable version of Log4j or Spring doesn't mean that you aren't using a Java component or development framework that relies on Log4j or Spring Beans. For example, Apache Struts2, ElasticSearch, Apache Kafka, among others, call on Log4j. Our co-founder and CTO, Chris Wysopal explained: “There… | Vulnerability | ||
|
2022-04-12 00:49:45 | Veracode Acquires ML-Powered Vulnerability Remediation Technology From Jaroona GmbH (lien direct) | On the heels of our significant growth investment from TA Associates, we are pleased to announce our acquisition of auto-remediation technology from Jaroona. Jaroona's intelligent remediation technology accelerates Veracode's vision and strategy to automatically detect and remediate software vulnerabilities. Jaroona was recognized as a Gartner Inc. 2021 Cool Vendor for DevSecOps1. Accelerated development practices and dependency on software have increased the software attack surface exponentially, placing a greater strain on development and security teams to ramp up security awareness and skills as well as find and fix flaws across an evolving technical environment. This investment will allow us to offer a unique benefit to our customers, leveraging our collective knowledge over nearly two decades of helping customers find and fix security flaws. This milestone is yet another step toward our vision to deliver a frictionless experience for developers to find and fix security flaws,… | Vulnerability | ★★★ | |
|
2022-04-01 19:51:15 | Spring4Shell Vulnerability vs Log4Shell Vulnerability (lien direct) | On March 29, 2022, details of a zero-day vulnerability in Spring Framework (CVE-2022-22965) were leaked. For many, this is reminiscent of the zero-day vulnerability in Log4j (CVE-2021-44228) back in December 2021. What is the difference between the vulnerabilities? The Spring Framework vulnerability was caused by unforeseen access to Tomcat's ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server. On the other hand, the Log4j vulnerability was the result of an exploitable logging feature. If the logging feature is successfully exploited on your infrastructure, attackers can perform an RCE (Remote Code Execution) attack and compromise the affected server. What is the scope of the vulnerabilities? Since we are a cloud-based Software Composition Analysis (SCA) provider, we are able to leverage data on the scope of the vulnerabilities. As we… | Vulnerability | ||
|
2022-03-31 12:15:17 | (Déjà vu) Spring Framework Remote Code Execution (CVE-2022-22965) (lien direct) | Details of a zero-day vulnerability in Spring Framework were leaked on March 29, 2022 but promptly taken down by the original source. Although much of the initial speculation about the nature of the vulnerability was incorrect, we now know that the vulnerability has the potential to be quite serious depending on your organization's use of Spring Framework. There is also a dedicated CVE 2022-22965 assigned to this vulnerability. We will keep this blog updated as new information comes up. Technical summary The cause was initially rumored to be related to deserialization, but the actual cause is due to unforeseen access to Tomcat's ClassLoader as a result of the new Module feature added in Java 9. An existing mitigation only blocked access to the classLoader property of Class objects, but the new Module object also has a classLoader property and was therefore accessible through Spring's property bindings when a Java object is bound to a request parameter. Access to the classLoader… | Vulnerability | ★★★★ | |
|
2022-03-31 12:15:17 | Spring Framework Remote Code Execution (lien direct) | Details of a zero-day vulnerability in Spring Framework were leaked on March 29, 2022 but promptly taken down by the original source. Although much of the initial speculation about the nature of the vulnerability was incorrect, we now know that the vulnerability has the potential to be quite serious depending on your organization's use of Spring Framework. There is also a dedicated CVE 2022-22965 assigned to this vulnerability. We will keep this blog updated as new information comes up. Technical summary Although the cause was initially rumored to be related to deserialization, the actual cause is due to unforeseen access to Tomcat's ClassLoader as a result of the new Module feature added in Java 9. An existing mitigation only blocked access to the classLoader property of Class objects, but the new Module object also has a classLoader property and was therefore accessible through Spring's property bindings when a Java object is bound to a request parameter. Access to the… | Vulnerability | ||
|
2022-03-22 17:35:44 | Shifting Log4j Discovery Right (lien direct) | You hear a lot about shifting your application security (AppSec) left – in other words, shifting AppSec to the beginning of the software development lifecycle (SDLC). While we firmly believe that you should continue scanning in development environments, that doesn't mean that you should neglect applications that have been deployed to or staged in runtime environments. Runtime presents a unique set of challenges – misconfigurations, logic errors and the like that can't be identified in a static or third-party scan. If you aren't testing for vulnerabilities at runtime, you are risking a potential breach of a different kind. As Chris Wysopal, our co-founder and CTO recently emphasized ... In a shift left world, shifting right is more important than ever. There are many examples that warrant shifting both left and right. Consider the recent zero-day vulnerability in Log4j 2.x reported on December 9, 2021. Log4j is a Java-based logging utility used by developers to keep track of what… | Vulnerability | ||
|
2021-12-10 11:59:05 | URGENT: Analysis and Remediation Guidance to the Log4j Zero-Day RCE (CVE-2021-44228) Vulnerability (lien direct) | A previously unknown zero-day vulnerability in Log4j 2.x has been reported on December 9, 2021. If your organization deploys or uses Java applications or hardware running Log4j 2.x your organization is likely affected. Technical summary Yesterday a new Log4J zero-day vulnerability was reported on Twitter: https://twitter.com/P0rZ9/status/1468949890571337731 . The first PoC (Proof of Concept) of the vulnerability is already available at the time of writing - https://github.com/tangxiaofeng7/apache-log4j-poc According to RedHat (source: https://access.redhat.com/security/cve/cve-2021-44228) it's rated as 9.8 CVSSv3 which is almost as bad as it gets. If successfully exploited on your infrastructure, it will result in attackers being able to perform a RCE (Remote Code Execution) attack and compromise the affected server. Given the relative simplicity of the exploit, it's likely that your incident response team will need to deal with an attack. There are multiple reports that the vulnerability is being actively exploited in the wild and needs to be patched promptly, there's already a patched Log4j version available: https://logging.apache.org/log4j/2.x/security.html Am I affected? To check whether your application is likely affected you must verify: Log4j version – all 2.x versions before 2.15.0 (released today, Friday, December 10, 2021) are affected JVM version - if lower than: Java 6 – 6u212 Java 7 – 7u202 Java 8 – 8u192 Java 11 - 11.0.2 If both are true, your Log4j version is older than 2.15.0 and your Java version patch level is older than listed above, you're almost certainly affected. At this time, it's likely that your internet-facing infrastructure may have been already compromised as this vulnerability is being actively exploited, according to this report: https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-acti… Please bear in mind that even if your application does not use log4j directly its surrounding infrastructure such as the application server, message queue server, database server, network devices may be using that combination of Java and log4j version that expose you to this vulnerability. Remediation Using Java 1.8 or higher? Download the latest Log4j mitigated version 2.15.0 from its download page. If you can't upgrade immediately and are using Java 8u121 or later If the Java version is >= 8u121 it is possible to mitigate the issue by setting com.sun.jndi.rmi.object.trustURLCodebase to false and com.sun.jndi.cosnaming.object.trustURLCodebase to falseIt's still preferable to update log4j version to secure one as soon as possible. Using Java version less than 1.8 Source: https://logging.apache.org/log4j/2.x/security.html In earlier versions of log4j >= 2.10 it is possible to mitigate this issue by Setting the system property formatMsgNoLookups: true Or Set the JVM parameter -Dlog4j2.formatMsgNoLookups=true Or Removing JndiLookup class from the classpath example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class How Veracode helps you to address this problem Thanks to our Software Composition Analysis (SCA) product, you can quickly verify whether an application portfolio that you're scanning with us is affected and at elevated risk of being exploited. To verify whether your applications are using vulnerable versions of log4j, log in to the Veracode Platform. Check versions of log4j that are dependencies of your applications by following this guide: https://docs.veracode.com/r/c_SCA_comps *Please note* Veracode SCA customers are able to scan for this vulnerability across their applications. The entry for the vulnerability in our database is here: https://sca.analysiscenter.veracode.com/vulnerability-database/libraries/apache-log4j-2/java/maven/lid-344173/summary Risk management procedures While the development teams work on finding the impacted applications and update all the relevant dependencies, it is advisable to update your Intrusion Prevention Systems (IPS) rulesets to gain more time to work on the remediat | Vulnerability | ||
|
2021-12-02 18:23:23 | Part 3: Using Veracode From the Command Line in Cloud9 IDE (lien direct) | In part three of a four-part series, Clint Pollock, principal solutions architect at Veracode, details how to use Veracode from the command line in the Cloud9 IDE to submit a software composition analysis (SCA) scan. Check out the video and step-by-step instructions below. It's Clint Pollock, principal solutions architect, back again for part three of our four-part series on using Veracode from the command line in Cloud9 IDE. If you haven't done so already, please check out part one on static policy scans and static sandbox scans and part two on the pipeline scanner. For part three, we will dive into open source and third-party libraries. Those are libraries that you don't generally fix. You just need to upgrade and keep an eye on these libraries to make sure that they don't have vulnerabilities. Now, inside of the Veracode application profile, there are results on static analysis and software composition analysis. In addition, if you had manual tests or dynamic scanning, you'll see those results there as well. When you run a static scan, you get a report for the first-party problem. And inside of software composition analysis, you get alerted to to any libraries that have vulnerabilities. You'll also be alerted to newer versions that you can upgrade to so that you don't have those vulnerabilities within your application. This happens automatically. And by default, there's also an SCA agent which gives additional information during your bill job or within your IDE about the third-party library and open source components that are out of date or have vulnerabilities. To set up an agent on your desktop or within your build server, you want to go to software composition analysis, and then agent-based scan. If you don't have these tabs, talk to the application security team. This section of our portal is dedicated to open source findings and problems within. You'll notice you can set up a workspace and then inside of that workspace, you can deploy agents. Agents can be installed on your desktop or in your CI/CD system so that you can get some additional functionality around third-party and open source library issues in your application. Go to agents, create a new agent, and choose your platform. You'll see there are lots of instructions for integrating with other build systems. There is an API token that you have to generate. And then basically just run the command. For installing my cloud nine IDE, choose that option. Once activated, go into the project folder and type in SRC:CLR scan. Now you see all this information that comes out into the actual terminal. There's a lot of problems here, and this application will require some real work to resolve all these issues. That's why you typically start with the very high and high severity items, but in the case of the SCA agent, you are getting one additional data point that is critical here. It's called vulnerable methods. Now the SCA agent is able to detect vulnerable methods, but just by uploading a static scan where you actually get the additional SCA results, it does not give us vulnerable methods. A vulnerable method is where you're actually calling the set of code, where the vulnerability exists in a given library. Therefore this would be considered something extremely high risk, and you should remediate any vulnerable methods as soon as possible by upgrading the library to a version that does not have the problem or replacing it with something else. Assume this particular app has a bunch of problems known as CVEs. This is data coming from the NIST database. Generally, if an open source library gets a problem, there'll be a NIST entry. The issue though is that this can be months after the initial problem has been discovered. So the second area that Veracode offers great value is the premium database. Use machine learning to go out and scour the GitHubs of the world to look at release notes for open source software. If there's any sort of security issues, our system will route that to humans to then be entered into our database. Therefore, you get a bi | Vulnerability | ||
|
2021-11-23 14:21:23 | Don\'t Let Code Injections Mess Up Your Holiday eCommerce Season (lien direct) | The holidays are right around the corner. It's a well-deserved time to spend with your friends and family, and it likely translates to increased online sales. But more eCommerce activity also means increased cybersecurity risks. Most organizations with eCommerce deploy cybersecurity measures such as Content Security Policies (CPSs), to help secure their site and protect their customer's personally identifiable information from a breach. Specifically, CSPs act to defend websites against online scripts that can cause fraud or steal credit card information. And while CSPs do represent a solid first line of defense, as we will soon explore, there is also so much more that organizations need to do to protect against malicious scripts and code injections. That's because CSPs are only as effective as your allow list, so if a hacker targets any services already used by your CSPs, attacks are easy to execute. In this article, we'll dive into how and why code injections are a threat to your web applications, why CSPs are effective but not enough to stop injections and additional measures that you can take to guard against code injections. How are code injections a threat to your web applications? A 'code injection' is a general security term used to refer to cyberattacks that involve injecting malicious code that will then be used by the infected application. It's worth noting that code injection is distinctively different from the similarly named command injection, in that with the latter the hacker is not limited by the functionality of the injected code. Injection flaws are still one of the most critical forms of security risk to web applications. Code injections are usually made possible as a result of poor handling of data. Specifically, code injections can arise as a result of no input or output data validation, which in layman's terms means that the data stored has not been properly 'sanitized.' The application receiving the user input expects to receive only certain types of input, but if a developer is negligent in regards to what can be accepted (such as in regards to format or accepted characters), the hacker can be successful. When a code injection attack is successful, the attacker has access to the database of the application. What are CSPs...and are they enough? A CSP is a set of rules that are defined by a web developer to either allow or block types of requests. This is intended to ensure stronger security for site visitors since it reduces the odds they will open an application on which malicious coding is running. For example, developers can use CSPs to block any code (such as JavaScript) from being uploaded from domains that are unfamiliar. It's ultimately the responsibility of the web application owner to define the CSP for their site, but it's often the developer(s) who will set and enforce those policies. An example of a CSP would be to make it so that all forms of visual media uploaded to a site must come from domains that are individually approved. This will prevent hackers from injecting malicious JavaScript into embedded videos or photos. Setting good CSPs like this is effective but, at the same time, they should never be treated as the only line of defense. There are a few reasons for this. The first is that CSPs can struggle to keep up with innovations in web development. To put this into perspective, if your site's development team is limited by a strict CSP, it's possible that your site could fall behind competitors in terms of innovative deployments Another problem is the fact that according to a recent Enterprise Strategy Group survey, over 76 percent of developers never received security training in their college IT programs. Your developer may not be experienced in, for example, secure coding best practices and may not be able to detect certain forms of malicious activity. You can help remedy this by offering secure code training. Guarding yourself against code injections One of the best cybersecurity strategies to guard your web applications against code injection | Vulnerability Threat | ||
|
2021-11-10 12:34:31 | Recent Updates to the OWASP Top Ten Web Application Security Risks (lien direct) | The Open Web Application Security Project (aka OWASP) recently announced its latest updates to the venerable OWASP Top Ten list. This publication is meant to bring attention to the most common classes of software-related security issues facing developers and organizations in the hopes of helping them to better plan for and address potential high-severity issues in their codebases. While not specifically an industry standard, it is highly regarded among the security community and is regularly combined with findings from application security vendors and researchers to create a reference point for secure coding practices. The newest edition does make updates to certain conventions but also highlights the consistent issues seen throughout the years, such as injection attacks and insecure components. Initially notable is the more generalized approach to categorization and naming, with OWASP describing the motivation for these changes as a “focus on the root cause over the symptom.” Given the complexity of modern web applications and software stacks, this new focus is a prudent reminder that focusing solely on the high-level presentation of flaws within complicated vulnerability taxonomies will only go so far in preventing breaches, and that true progress at any scale will only be made by remediations that address the underlying cause of discovered issues. Supporting this focus is the inclusion of the new category A04:2021 – Insecure Design, bringing attention to the ever-growing need to address vulnerable application architectures and software flaws much earlier in the development process. While there has been considerable discussion about the industry's need to “shift left” for the past several years, it is apparent that a lack of threat modeling and overall secure design continues to be a major issue for applications of all types. It is nice to see these concerns formally addressed at this level in the broader context of security risk awareness. The addition of A08:2021 – Software and Data Integrity Failures and the higher ranking for A06:2021 – Vulnerable and Outdated Components both appear to be in a similar vein, further underscoring the need for organizations to prioritize the security controls associated with the development pipeline and surrounding technologies as much as the specifics of the application code itself. The frameworks, software libraries, and other tools that development teams rely on are updated with increasing speed. It is easier than ever for organizations to fall behind on patching and management of these supporting components. These areas will continue to be points of security concern for years to come, and the industry should continue the work of better addressing the role of tooling and pipeline concerns, as well as application threat modeling, within the general scope of security issues across the board. The movement of A01:2021 – Broken Access Control to the number one position, while hardly a surprise, is reason for concern primarily due to the obstacles associated with detecting issues of this nature. Underlying many access control flaws are fundamental application logic errors, most of which are currently difficult, if not impossible, to discover with automated scanning of any kind. As most companies are unable to have penetration testers examine every release, applications may only undergo thorough manual security audits relatively infrequently, leaving a large footprint of possible flaws whose discovery and remediation times are measured in months, or even years. Further complexity is introduced as modern web technologies move toward microservice architectures and application containerization, creating a need to test for access control issues related to the nuances of these components as well. While teams may do their best to adhere to a least-privilege model, it quickly becomes more difficult to follow best practice guidelines as additional endpoints and APIs are added and role managemen | Vulnerability Threat Patching | ||
|
2021-11-02 14:09:27 | Champion Spotlight: Cris Rodriguez (lien direct) | This interview was cross-posted from the Veracode Community. Join us in congratulating Cris, the latest Secure Code Champion in the Veracode Community! The Secure Code Champion is an award that recognizes individuals with three championships in the Veracode Community's Secure Coding Challenge competitions. Cris is a principal-level Application Security engineer in a large global travel technology company. In this role, he focuses on application penetration testing and setting the strategy for migrating their apps over to Google Cloud. Before entering the security space, he was a software developer for five years. In this interview, we asked Cris about this experience participating in the Secure Coding Challenges and his career change story. He talked about how he made the career switch from a developer to become a security engineer, and what he thinks is important for someone to be successful in this role. For developers considering a similar career move, he also shared the resources that he found most helpful. About Your Experience in the Secure Coding Challenge What brought you to the Secure Coding Challenge? I got an email about the competition and I enjoy a good challenge. What did you find most valuable in participating in the Challenge? Since there were multiple languages, we were able to experience different solutions for a single bug class. That was helpful since most companies use many languages for their apps. What's your suggestion for participants to stand out in the competition? Trust your instincts and be familiar with using a command line and coding project directory tree. As a security engineer, you'll need to be able to dig into your organization's code if you want to be able to help your developers succeed. About Your Experience Becoming a Security Engineer How have you grown from a software developer into a Security engineer? What are the skillsets and knowledge required for this career change? How did you acquire those skills? I was a software developer for five years before I switched over to security. When I made the switch, I was focusing on penetration so I read as many bug bounty write-ups as I could find and watched many more YouTube tutorials. Hack the box and pentester academy have been very helpful in my learnings. What are the top 3 qualities of a successful security engineer? Attention to detail:We are looking for bugs in code that work so you have to understand what makes a component vulnerable. Communication:The developers are going to push back sometimes so being able to communicate with them is key Vulnerability Knowledge:When the developers push back on a vulnerability you really need to have the knowledge of why it is important to fix it. It also helps if you can demonstrate how the vulnerability can be exploited. Is there any tool, resource, forum/meet-up, or course you'd recommend for developers looking to break into the security world? Read the disclosed write-ups at HackerOne and Bugcrowd. Also, here is a link to a great repo that gathered a lot of write-ups. https://github.com/devanshbatham/Awesome-Bugbounty-Writeups Questions about becoming a security engineer? Or, if you're a fellow security engineer, let's connect! You can follow me on Twitter @Nimbus689 or connect with me on LinkedIn. https://www.linkedin.com/mwlite/in/cristobal-rodriguez-03b3b079 | Hack Vulnerability | ||
|
2021-10-29 14:31:12 | Software Composition Analysis Mitigates Systemic Risk in the Popular NPM Repository (lien direct) | Chris Wysopal, Veracode Chief Technology Officer and Co-Founder, recently sat down to discuss the open source supply chain attack on the popular npm repository. Below is the transcript and corresponding video of his reaction. Just a few days ago, we saw a classic open source supply chain attack where someone modified a JavaScript library, UA-Parser-JS, which is in the npm repository. The attackers modified the library to include password stealers and crypto miners so that the applications of anyone who downloaded that version would be compromised. With an attack like this, the applications that are using this library with this code are going to be running that code with the privileges that they have, wherever they're deployed. In this case, it was malicious code that was planted. I'm sure it was done in such a way that everyone using those libraries is going to become vulnerable. If it's password-stealing code, it's going to grab the passwords and send them to the attackers. In the case of crypto miners, it's going to suck up resources and CPU time and send the money to the attacker's wallets. It's important if you're using any kind of open source – which 99 percent of people building applications are – to use an open source software composition analysis (SCA) tool. What that can do is determine what open source you're using. Veracode SCA does this. Another important thing to do is make sure the vulnerability database that your SCA tool uses is current and up to date. At Veracode, we scan all the open source repos every single night. When this malicious code was inserted, we detected it right away. All of our customers were alerted that if they're using this version of the code, they need to update to the non-vulnerable version immediately. Veracode's recent State of Software Security: Open Source Edition report shows that 79 percent of the open source libraries that developers include are set it and forget it, which means they include it once and they never update it. But the updates tend to be relatively straightforward. In fact, 92 percent of open source flaws can be fixed with an update. And 69 percent of updates are a minor version change or less. It is really important to have good and timely information about the vulnerabilities in the libraries you're using and a good process for updating the libraries … hopefully in a very automated manner. That way you're updating these libraries without any manual effort, probably in minutes or hours instead of months. That could be the difference between an attacker compromising you or not. This is why it's so important to stay on top of all the known vulnerabilities in the open source libraries you're using as part of your application, because when you include that third-party code, your application is likely to become vulnerable to those same problems. Don't fall victim to an open source attack. Learn how Veracode Software Composition Analysis can protect your code. Want to stay up to date on the latest Veracode news? Sign up for our monthly newsletter. | Tool Vulnerability | ||
|
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-09-10 08:25:31 | 2003 Testimony to Congress Proves That We Still Have a Long Way to Go In Building Secure Software (lien direct) | Back in May 1998, as a member of the hacker think tank, L0pht, I testified under my hacker name, Weld Pond, in front of a U.S. Senate committee investigating government cybersecurity. It was a novel event. Hackers, testifying under their hacker names, telling the U.S. government how the world of cybersecurity really was from those down in the computer underground trenches. Many in the security community know of the famous L0pht Senate testimony, but very few know that one of the L0pht members testified on Capitol Hill 5 years later. That member was me. This time I testified as a cybersecurity professional using my real name. I was the director of research and development at @stake, an information security consulting company. Back in the summer of 2003, the internet was plagued with worms such as Blaster and Sobig. The U.S. House of Representatives Committee on Government Reform wanted to hold hearings to understand the problem. Why had 400,000 computers been infected with Blaster in less than five days when the patch that would have prevented the attack had been available for over a month? I was asked to testify to help the committee understand vulnerability research. How were the vulnerabilities discovered that lead to worms like Blaster, and why were these latent vulnerabilities there in the first place? The problems I spoke of in 2003, sadly, are still here with us 18 years later. Large amounts of software are still not designed defensively… and not built with security testing embedded in the development process. The economics of software development still leads to the reuse of old insecure software. Computer users still loath updating to new, more secure versions of software due to costs and resources required. I discussed how the root cause of viruses and worms was security flaws in the design or implementation of software. I still believe this today (even though most vulnerabilities are not “wormable” or attackers choose to attack with more precision). I discussed the problems with a ship-it-vulnerable, patch-it-later approach. Even now with some products using auto-updating, patching is often late or doesn't happen at all due to the resources required to patch in an enterprise IT environment. Most of what I spoke of was the world of vulnerability research. Who were the people – like the researchers from the Last Stage of Delirium – that discovered the Blaster vulnerability? Why would they do this? How did they do this? How is it possible that they found a security bug when the vendor didn't? Then I spoke about the safe vulnerability disclosure process: How researchers could work with vendors to keep the internet safer despite vulnerable software everywhere. This type of process is now widely followed by researchers and vendors and is codified into an ISO standard. We have made progress on the challenge of building software more securely, distributing patches better, and handling vulnerability disclosure better. But the gains are far less substantial than they should be after 18 years. In my 2003 testimony, I said, “The current flawed computing infrastructure is not going to change for the better overnight. It will take many years of hard work.” We are still in the “many years” phase and perhaps will be for another decade. Take a look at my 2003 testimony and see for yourself just how far we still need to go. | Vulnerability Patching Guideline | ||
|
2021-08-19 08:10:39 | Veracode Ranked as a Strong Performer in Forrester Wave™ Software Composition Analysis Report (lien direct) | Veracode has been recognized in a report Forrester Research recently released, The Forrester Wave™: Software Composition Analysis, Q3 2021. The report helps security professionals select a software composition analysis (SCA) vendor that best fits their needs. The report, which evaluates 10 SCA vendors against 37 criteria, ranks Veracode as a strong performer. The Forrester Wave™ states, “Veracode is a strong choice for customers that are most interested in remediating vulnerabilities in open source components.” Noted in the report is our roadmap, which “...focuses on unifying the SAST and SCA capabilities in the developer environment and enhancing container and IaC security capabilities.” The report also highlighted, “Veracode has concentrated its SCA solution on finding and remediating open source vulnerabilities, with dependency graphs and guidance on a fix's likelihood to break the code - one customer's reference called the dependency graph 'amazing'.” Why is SCA such a critical element of software development? As Forrester explains, “Open source use has exploded, with the average percentage of open source in audited code bases increasing from 36% in 2015 to 75% in 2020.” But we know from Veracode's recent State of Software Security (SOSS): Open Source Edition report that about 79 percent of developers never update third-party libraries after including them in their codebase, which leads to unnecessary breaches. With tools like Veracode Software Composition Analysis in hand, developers have the power to assess and manage the risk of their open source components by scanning open source dependencies for known flaws and leaning on data-driven recommendations for version updating. In fact, our SOSS research unveiled that 92 percent of third-party flaws can be remediated with an update and 69 percent of the updates are minor. Learn more Download The Forrester Wave™: Software Composition Analysis, Q3 2021 report to learn more about what to look for in a software composition analysis vendor and for additional information on Veracode's strong performer ranking in vulnerability detection and remediation. | Vulnerability Guideline | ||
|
2021-07-14 09:53:51 | Key Takeaways for Developers From SOSS v11: Open Source Edition (lien direct) | Our latest State of Software Security: Open Source Edition report just dropped, and developers will want to take note of the findings. After studying 13 million scans of over 86,000 repositories, the report sheds light on the state of security around open source libraries – and what you can do to improve it. The key takeaway? Open source libraries are a part of pretty much all software today, enabling developers to work faster and smarter, but they're not static. Library popularity and usage changes and evolves with trends in software development, and if developers don't keep up with these movements, the organizations they're building innovative applications for are at greater risk of damaging data leaks and cyberattacks. Let's dive into the data. Just over half of developers have a process for selecting third-party libraries As part of this year's report, we ran a survey that asked customers some critical questions about how they interact with third-party libraries. We weren't surprised to see that the customers who put effort into purchasing scanning software have a formal process in place for library evaluation; over half, 52 percent, said yes. The bad news is that a pretty big fraction of respondents (29 percent) are unsure of whether or not they have a formal process in place, while 19 percent said no. While a number of factors might contribute to this problem from company to company, a likely cause is the lack of a developed, shared, and followed policy – something that can be tricky for larger, dispersed teams to manage without all of the DevSecOps puzzle pieces in place. Developers can act fast if they're given the right information, early We know that most developers don't go out of their way to ignore security, so where's the disconnect between how quickly flawed libraries are fixed? The data shows us that when developers have the right information in hand sooner rather than later – for example, contextual information about how a vulnerable library relates to an app – they're able to fix those flawed libraries quickly. In fact, we found that 17 percent of flawed libraries are fixed within an hour of the security scan, while 25 percent are fixed within seven days. There was little change in popularity for Java, but big changes in Swift You'll see above in figure 1 that while some languages like Java didn't change much year over year, others like Swift had quite the shakeup. Swift's top two libraries from 2019, Crashlytics and Fabric, didn't even make it into the top 20 last year. But we know why that happened – Google is the parent company behind Firebase, which acquired Crashlytics and Fabric, giving those two libraries both a boost in popularity. Jackson-databind is popular and vulnerable, while Twisted saw a drop When we looked at the top vulnerable libraries from 2019 and 2020, something jumped out at us for Java. The popular jackson-databind library was both popular and vulnerable, holding steady year over year. However, the Twisted library in Python tells a different story. Note how it dropped dramatically in popularity from 2019 to 2020 in figure 2. We can likely attribute this to the expanding capabilities of functionality within Python as well as the fact that Twisted has had seven CVEs associated with it over the course of its lifetime. The majority of library vulnerabilities are fixable with minor updates It might surprise you that most vulnerabilities in third-party libraries are easy to fix with a minor update. When we dug into the data we found that a whopping 92 percent of flaws can be fixed with a simple update, while 69 percent of updates are a minor version change or less. This means that, having the right contextual information about the flawed libraries and the apps they impact in hand sooner rather than later, developers should be able to update libraries quickly and efficiently. But… …Most libraries are never updated at all Here's where developers seem to run into a wall when it comes to fixing flawed third-party libraries. Fig | Vulnerability | ||
|
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 |
To see everything:
Our RSS (filtrered)
