core
core copied to clipboard
thoth-station
[Spike][8pt]Perform dynamic source code analysis to give more security related guidenance
Is your feature request related to a problem? Please describe.
I, as a Thoth user, would like to consume recommendations that are derived out of dynamic source code analysis. As of now, we provide results of static source code analysis in SI workflow (derived out of tools such as bandit and cloc). Besides these static analyzers, I would like to know aspects of my application with respect to code execution.
Describe the solution you'd like
Provide a way to run dynamic source code analyzers in Thoth.
Additional context
See for example this article stating a similar solution:
https://jordan-wright.com/blog/post/2020-11-12-hunting-for-malicious-packages-on-pypi/
It might be a good idea to provide this functionality within the data aggregation workflow, but also - having a service that would check syscalls of an already existing application before pushing it to prod (e.g. to verify no data are leaked, no external communication is done) can be beneficial in many cases.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@sesheta: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@fridex: This issue is currently awaiting triage.
One of the @thoth-station/devsops will take care of the issue, and will accept the issue by applying the
triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@sesheta: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
maybe also interessting https://archive.fosdem.org/2019/schedule/event/containers_kubectl_trace/
Suggestions:
- [ ] [Spike]OSSF has an implementation of the this, maybe we can include these in prescriptions.
BTW it might be also good to check if this data source would be suitable for solver rules to automatically block malicious packages based on OpenSSF's scans.