Skip to content
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

Add annotations for data sources and sinks and further static analysis #385

Open
emkll opened this issue May 23, 2019 · 5 comments
Open
Assignees
Labels

Comments

@emkll
Copy link
Contributor

emkll commented May 23, 2019

Pyre [0] allows for further static analysis to ensure untrusted and/or unsanitized input never makes it it's way through to sensitive functions.

We should add annotations for sources, sanitizers and sinks across the codebase in order for this static analysis to run.

[0] : https://pyre-check.org/docs/static-analysis-post-processor.html

@emkll emkll added the security label May 23, 2019
@redshiftzero
Copy link
Contributor

for the interested observer, check out the talk from Pycon 2019 for background on this

@kushaldas
Copy link
Contributor

pyre static analysis works in example code, but, I could not find any other project on Github using this. i tried to add the minimal along with adding eval calls, which should cause red flags. But, could not do it easily. I have pinged my friends to get more direct connection to the upstream community, but, nothing mentions in the documentation as a community place, I personally think we should wait before starting to use it.

@eloquence
Copy link
Member

We still agree that static analysis would be useful here, want to further investigate pyre and/or alternatives, so keeping on near-term backlog.

@ghost
Copy link

ghost commented May 17, 2022

Picking up on this a little bit:

I'd like to try to implement pysa (pyre's name for the taint analysis tool; it's the same thing that's linked in the original post) as a part of the CI. The idea would be to apply it to PR's, diffing the output of the taint analysis on the PR and the branch it'd be merging into.

Of particular note: pysa doesn't specifically target vulnerabilities, but simply does taint analysis, which can in turn lead to identifying vulnerabilities. This means that it can be quite verbose, so the aim here is to start with a config that won't overwhelm developers with tons of warnings. Further work can allow us to minimize the noise and get more relevant output.

I'm aiming to add a draft PR soon

@cfm
Copy link
Member

cfm commented Jun 26, 2024

Based on freedomofpress/securedrop#6111 (comment), I think it might be worth a research spike someday soon on Semgrep's cross-file taint analysis, in service of the requirement that "attacker-provided text should be rendered as plaintext".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants