Open fridex opened 3 years ago
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
/remove-lifecycle stale
Part of the planned intern project.
/priority backlog /sig indicators
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.
@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.
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.
/lifecycle frozen
maybe also interessting https://archive.fosdem.org/2019/schedule/event/containers_kubectl_trace/
/remove-lifecycle frozen /lifecycle active
/assign @mayaCostantini /assign @fridex
/sig stack-guidance
/remove-lifecycle active
/lifecycle frozen
Suggestions:
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.
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.