# US 12,001,565 B2 · False-positives invalidation and static security scans without scanning based on regular scan history in pull requests > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 12,001,565 B2 - Document ID: US12001565B2 - Status: Granted - Kind: B2 - Application number: 17/301,767 - Filed: 2021-04-14 - Published: 2022-10-20 - Granted: 2024-06-04 - Earliest claimed: 2021-04-14 - Assignees: International Business Machines Corporation - Applicants: International Business Machines Corporation - Inventors: Marcin Filip; Michal Bodziony; Marcin Luczynski; Tomasz Zatorski; Wojciech Mis; Bartosz Tomasik - Web page: https://patentgrep.com/patent/US12001565B2 ## CPC - G06F 21/577: {Assessing vulnerabilities and evaluating computer system security} - G06F 2221/033: Test or assess software - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract Providing an automatic mechanism of invalidating false-positive indications of certain identified portions of source code to reduce the number of errors in a security report. Certain embodiments of the present invention utilize static security scanning as a mechanism for automatically determining which portions of the identified source code contain potential vulnerabilities, and whether these identified portions of the source code are correctly or incorrectly identified with a false-positive indication. ## Claims ### Claim 1 A method comprising: receiving, from a target repository, a set of source code from a first operating environment; scanning, during a pull request of the target repository, the set of source code; determining, by a security determination module, that a first subset of the source code includes a security vulnerability; analyzing the first operating environment for the set of source code and the target repository, with the analysis including determining whether the first operating environment for the set of source code and the target repository have a set of storage device controllers that are structured and configured to support the set of source code and the target repository; responsive to the analysis of the first operating environment, determining that the security vulnerability of the first subset of the source code cannot be exploited; responsive to the determination, returning a false positive notification for the security vulnerability; and setting up a trigger for invalidating a false positive based, at least in part, on which group of false positives is invalidated, the trigger for invalidating the false positive being set up in order to reduce a time spent re-analyzing false positives, the trigger for invalidating the false positive, during a next scan, unmarking the false positive and forcing a scanner to check again for false positives. ### Claim 2 (depends on 1) The method of claim 1 wherein the false positive notification for the security vulnerability is returned in response to a first pull request. ### Claim 3 (depends on 1) The method of claim 1 wherein the determination that the security vulnerability cannot be exploited is based, at least in part, upon running a script that matches the first subset of source code to code that contains recognized vulnerabilities. ### Claim 4 (depends on 3) The method of claim 3 wherein matching the first subset of source code to the code that contains recognized vulnerabilities is calculated by using a Levenshtein Distance. ### Claim 5 (depends on 1) The method of claim 1 wherein the false positive notification is returned for the security vulnerability based, at least in part, upon a determination that the first set of source code was run on a first web browser. ### Claim 6 (depends on 1) The method of claim 1 wherein the false positive notification is returned for the security vulnerability based, at least in part, upon a determination that the first set of source code was run in a non-native operating environment. ### Claim 7 A computer program product (CPP) comprising: a machine-readable storage device; and computer code stored on the machine-readable storage device, with the computer code including instructions and data for causing a processor(s) set to perform operations including the following: receiving, from a target repository, a set of source code from a first operating environment, scanning, during a pull request of the target repository, the set of source code, determining, by a security determination module, that a first subset of the source code includes a security vulnerability, analyzing the first operating environment for the set of source code and the target repository, with the analysis including determining whether the first operating environment for the set of source code and the target repository have a set of storage device controllers that are structured and configured to support the set of source code and the target repository, responsive to the analysis of the first operating environment, determining that the security vulnerability of the first subset of the source code cannot be exploited, responsive to the determination, returning a false positive notification for the security vulnerability, and setting up a trigger for invalidating a false positive based, at least in part, on which group of false positives is invalidated, the trigger for invalidating the false positive being set up in order to reduce a time spent re-analyzing false positives, the trigger for invalidating the false positive, during a next scan, unmarking the false positive and forcing a scanner to check again for false positives. ### Claim 8 (depends on 7) The CPP of claim 7 wherein the false positive notification for the security vulnerability is returned in response to a first pull request. ### Claim 9 (depends on 7) The CPP of claim 7 wherein the determination that the security vulnerability cannot be exploited is based, at least in part, upon running a script that matches the first subset of source code to code that contains recognized vulnerabilities. ### Claim 10 (depends on 9) The method of claim 9 wherein matching the first subset of source code to the code that contains recognized vulnerabilities is calculated by using a Levenshtein Distance. ### Claim 11 (depends on 7) The CPP of claim 7 wherein the false positive notification is returned for the security vulnerability based, at least in part, upon a determination that the first set of source code was run on a first web browser. ### Claim 12 (depends on 7) The CPP of claim 7 wherein the false positive notification is returned for the security vulnerability based, at least in part, upon a determination that the first set of source code was run in a non-native operating environment. ### Claim 13 A computer system (CS) comprising: one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, wherein the computer system is capable of performing a method comprising: receiving, from a target repository, a set of source code from a first operating environment, scanning, during a pull request of the target repository, the set of source code, determining, by a security determination module, that a first subset of the source code includes a security vulnerability, analyzing the first operating environment for the set of source code and the target repository, with the analysis including determining whether the first operating environment for the set of source code and the target repository have a set of storage device controllers that are structured and configured to support the set of source code and the target repository, responsive to the analysis of the first operating environment, determining that the security vulnerability of the first subset of the source code cannot be exploited, responsive to the determination, returning a false positive notification for the security vulnerability, and setting up a trigger for invalidating a false positive based, at least in part, on which group of false positives is invalidated, the trigger for invalidating the false positive being set up in order to reduce a time spent re-analyzing false positives, the trigger for invalidating the false positive, during a next scan, unmarking the false positive and forcing a scanner to check again for false positives. ### Claim 14 (depends on 13) The CS of claim 13 wherein the false positive notification for the security vulnerability is returned in response to a first pull request. ### Claim 15 (depends on 13) The CS of claim 13 wherein the determination that the security vulnerability cannot be exploited is based, at least in part, upon running a script that matches the first subset of source code to code that contains recognized vulnerabilities. ### Claim 16 (depends on 15) The CS of claim 15 wherein matching the first subset of source code to the code that contains recognized vulnerabilities is calculated by using a Levenshtein Distance. ### Claim 17 (depends on 13) The CS of claim 13 wherein the false positive notification is returned for the security vulnerability based, at least in part, upon a determination that the first set of source code was run on a first web browser. ### Claim 18 (depends on 13) The CS of claim 13 wherein the false positive notification is returned for the security vulnerability based, at least in part, upon a determination that the first set of source code was run in a non-native operating environment.