-
Notifications
You must be signed in to change notification settings - Fork 467
fix(iast): avoid excessive filtering of stacktrace locations #13272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
Bootstrap import analysisComparison of import times between this PR and base. SummaryThe average import time from this PR is: 232 ± 2 ms. The average import time from base is: 234 ± 2 ms. The import time difference between this PR and base is: -1.73 ± 0.1 ms. Import time breakdownThe following import paths have shrunk:
|
BenchmarksBenchmark execution time: 2025-05-06 11:08:05 Comparing candidate commit f2c630e in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 388 metrics, 5 unstable metrics. scenario:iast_aspects-ospathnormcase_aspect
|
0a215f0 to
afe4076
Compare
6df3fdf to
9e40427
Compare
6dd320a to
af5a923
Compare
ed7e891 to
d37dbc4
Compare
|
Pushed a fix to avoid serializing empty location fields in IAST, in a commit here to validate it, and in a separate PR: #13333 |
d37dbc4 to
f2c630e
Compare
|
The backport to To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.21 2.21
# Navigate to the new working tree
cd .worktrees/backport-2.21
# Create a new branch
git switch --create backport-13272-to-2.21
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 20a96bb791aa98657ba85e77032f670a0ea1b028
# Push it to GitHub
git push --set-upstream origin backport-13272-to-2.21
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.21Then, create a pull request where the |
Current stacktrace filtering code returned no location if all frames are outside the current working directory or in site-packages. This often happens in the following scenarios: - asyncio code: the full stacktrace may be in site-packages, outside app directory. - running applications installed in site-packages. In these cases, vulnerabilities were being dropped. The fix includes: - First, the first frame that is not a frozen package (or `<template>` or anything starting with `<`), and not in the stdlib path (but potentially in the purelib path) is found and saved as a backup frame, if any. If none is found, no location is returned. - From there, the first frame that is not a frozen package, not in the stdlib path, and not in the purelib path is checked. If found, that location is returned. Otherwise, the backup frame is returned. - Code to relativize path to the vulnerability location is now extended to account for the fact that we can return paths within the purelib path. In practice, this means that vulnerabilities found in site-packages, with no other relevant frame, will be reported. [APPSEC-57414](https://datadoghq.atlassian.net/browse/APPSEC-57414) - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) [APPSEC-57414]: https://datadoghq.atlassian.net/browse/APPSEC-57414?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ (cherry picked from commit 20a96bb)
Current stacktrace filtering code returned no location if all frames are outside the current working directory or in site-packages. This often happens in the following scenarios: - asyncio code: the full stacktrace may be in site-packages, outside app directory. - running applications installed in site-packages. In these cases, vulnerabilities were being dropped. The fix includes: - First, the first frame that is not a frozen package (or `<template>` or anything starting with `<`), and not in the stdlib path (but potentially in the purelib path) is found and saved as a backup frame, if any. If none is found, no location is returned. - From there, the first frame that is not a frozen package, not in the stdlib path, and not in the purelib path is checked. If found, that location is returned. Otherwise, the backup frame is returned. - Code to relativize path to the vulnerability location is now extended to account for the fact that we can return paths within the purelib path. In practice, this means that vulnerabilities found in site-packages, with no other relevant frame, will be reported. [APPSEC-57414](https://datadoghq.atlassian.net/browse/APPSEC-57414) (cherry picked from commit 20a96bb)
Current stacktrace filtering code returned no location if all frames are outside the current working directory or in site-packages. This often happens in the following scenarios: - asyncio code: the full stacktrace may be in site-packages, outside app directory. - running applications installed in site-packages. In these cases, vulnerabilities were being dropped. The fix includes: - First, the first frame that is not a frozen package (or `<template>` or anything starting with `<`), and not in the stdlib path (but potentially in the purelib path) is found and saved as a backup frame, if any. If none is found, no location is returned. - From there, the first frame that is not a frozen package, not in the stdlib path, and not in the purelib path is checked. If found, that location is returned. Otherwise, the backup frame is returned. - Code to relativize path to the vulnerability location is now extended to account for the fact that we can return paths within the purelib path. In practice, this means that vulnerabilities found in site-packages, with no other relevant frame, will be reported. [APPSEC-57414](https://datadoghq.atlassian.net/browse/APPSEC-57414) (cherry picked from commit 20a96bb)
Current stacktrace filtering code returned no location if all frames are outside the current working directory or in site-packages. This often happens in the following scenarios:
In these cases, vulnerabilities were being dropped. The fix includes:
<template>or anything starting with<), and not in the stdlib path (but potentially in the purelib path) is found and saved as a backup frame, if any. If none is found, no location is returned.In practice, this means that vulnerabilities found in site-packages, with no other relevant frame, will be reported.
APPSEC-57414
Checklist
Reviewer Checklist