Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-30333PUBLISHED: 2022-05-09RARLAB UnRAR before 6.12 on Linux and UNIX allows directory traversal to write to files during an extract (aka unpack) operation, as demonstrated by creating a ~/.ssh/authorized_keys file. NOTE: WinRAR and Android RAR are unaffected.
CVE-2022-23066PUBLISHED: 2022-05-09
In Solana rBPF versions 0.2.26 and 0.2.27 are affected by Incorrect Calculation which is caused by improper implementation of sdiv instruction. This can lead to the wrong execution path, resulting in huge loss in specific cases. For example, the result of a sdiv instruction may decide whether to tra...
CVE-2022-28463PUBLISHED: 2022-05-08ImageMagick 7.1.0-27 is vulnerable to Buffer Overflow.
CVE-2022-28470PUBLISHED: 2022-05-08marcador package in PyPI 0.1 through 0.13 included a code-execution backdoor.
CVE-2022-1620PUBLISHED: 2022-05-08NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 in GitHub repository vim/vim prior to 8.2.4901. NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 allows attackers to cause a denial of service (application crash) via a crafted input.
User Rank: Apprentice
9/24/2015 | 12:58:29 PM
Of course there would be pushback ... unless the developer is compensated for secure code.
But what if accurate application security vulnerabilities could be identified before code check-in without any of the steps mentioned above? What if the applciation security vulnerabilities were identified simply from the FUNCTIONAL development and usage of the system?
As a former developer (and current AppSec tooling guy), I am always looking for ways to invisibly inject security into the SDLC ... ways that do NOT require a new line item in a project plan, an extra step in the coding / development process, or a self-imposed "wait state" in order to get application security results ... and, ideally, to have appication security vulnerabilities identified continuously and in real-time as an invisible and natural by-product of the process of building and testing software in an SDLC without regard for "Security Testing".
I have found that passive IAST products are capable of achieving this goal and not only enabling developers to identify and fix their vulnerabilities before the code leaves their desktop, but actually proactively reaching out to them to show the exact line of code that is vulnerable ... ALL WITHOUT A SCAN or extra step ... all in real-time from performing the very act that all developers do before checking in code ... FUNCTIONAL sanity/smoke testing.
Contrast Security provides such a solution.