CVE | CWE

15 CWEs were “On the Cusp” of making the “2024 #CWE Top 25 Most Dangerous Software Weaknesses” list.    These CWEs continue to be prevalent & severe enough to cause concern.    See the “2024 On the Cusp” list here: https://lnkd.in/eR7fzxY3

New Call for Papers Deadline for “VulnCon 2025” — January 31, 2025    #CVE Program and #FIRST will co-host #VulnCon2025 in Raleigh, North Carolina, USA, on April 7–10, 2025. Registration, both virtual & in-person, is open on the FIRST website    https://lnkd.in/e--BVia4

“CNA Enrichment Recognition” - 236 CNAs on the list for January 13, 2025     Published every 2 weeks, this list recognizes those CVE Numbering Authorities (#CNAs) actively providing #CVSS and #CWE vulnerability data in their #CVE Records    https://lnkd.in/e-dX5SmW

Check out this Help Net Security interview with #CWE Program Lead Alec Summers @ the “2024 CWE Top 25 Most Dangerous Software Weaknesses” list trends, role of the #CVE CNA, use of #AI tools, & other insights  https://lnkd.in/d8xV7nGS

Submit your #CFP for #VulnCon2025 today to be a part of the 40+ action-packed sessions😎🔗 https://go.first.org/MPudV #vulnerabilitymanagement #CVE #CVSS #EPSS #CISA #MITRE #VEX #Raleigh

524 CVE Records + severity scores when available in CISA’s Vulnerability Summary bulletin for the week of December 30, 2024    https://lnkd.in/eUKcP3Ak     #CVE #CVEID #CVSS #CWE #Vulnerability #VulnerabilityManagement #HSSEDI #CISA

Just saw this critique by Jim Manico that "CWE-89 is wrong" by emphasizing "neutralization of dangerous characters" and figured I'd weigh in here, as I believe there's some important nuance. Great comment Jim, and I look forward to the discussion! Hope this clarifies more than it obfuscates :) I struggle with the language to explain some of this mindset. Some background: as CWE technical lead since ~2006, I've tried to ensure that CWE entries focus on the specific mistake / behavior that is doing "the wrong thing." For general weaknesses, it can be difficult to ferret out what "the wrong thing" is, but I've come to strongly believe that "you didn't apply a particular mitigation [control]" is not the way to go, because for most weaknesses, there can be any number of different mitigations/controls that could be applied. And if a programmer applies mitigation X that fixes the weakness, they shouldn't get penalized because they didn't also apply mitigations Y and Z. So, characterizing a CWE entry as an "absence of a particular mitigation" is not ideal. Jim's proposal that CWE-89 is about "[not] using query parameterization" is focused on the most well-known, most effective <mitigation> that avoids SQL injection. Note that query parameterization is specifically listed as one of several mitigations in CWE-89. In all/many injection cases, there are many different mitigations that could be applied, which will vary depending on the product's design, programming language, framework, libraries, etc. The mitigations could be very specific to the particular vulnerability in the code. What enables "SQL injection" as an attack could be as simple as not validating that an input is a number instead of a string with arbitrary characters; an authorization issue where an untrusted user is inadvertently allowed to access functionality that intentionally allows admins to manipulate SQL queries; etc. You could even be "building your parameterized query insecurely" in a way that allows SQL injection - but clearly if you're already building a parameterized query, you're not subject to the "you're not using parameterized queries" weakness - so how could these kinds of "SQL injection" be handled? The point of CWE-89 and other CWEs related to neutralization/injection is: independent of the myriad mitigations that could be performed, the developer has not ensured the clear syntactic boundaries between "data" and "control." Using query parameterization is one way (of several) in which these boundaries can be enforced. The general point applies across other kinds of injection, for which query parameterization may not be a readily available solution. And consider the langsec folks who've proposed other solutions for injection that are not really the same as, parameterized queries. Note that I regularly struggle with distinguishing between "mitigations" and "weaknesses", especially because there is (appropriately) an increasing emphasis on secure development and design.

“VulnCon 2025” Call for Papers Closes January 15    The #CVE Program and #FIRST will co-host #VulnCon2025 at the McKimmon Center in Raleigh, North Carolina, USA, on April 7–10, 2025. Registration, both virtual and in-person, is open on the FIRST website    https://lnkd.in/eXVcp_Rz

CVE Program Expands Partnership with Thales Group — Thales Group is now designated as a Root for products and technologies of subsidiaries of Thales Group   Learn more:  https://lnkd.in/eveMFSr9     #CVE #VulnerabilityManagement #Vulnerability #Cybersecurity

PTC is now a CVE Numbering Authority (CNA) assigning CVE IDs for all currently supported PTC software products and cloud/SaaS services    https://lnkd.in/etaqyZ3C    #CVE #CNA #VulnerabilityManagement #Vulnerability #Cybersecurity