-
Notifications
You must be signed in to change notification settings - Fork 36
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
Fine grained control at package level #28
Comments
This is a good feature to support. Would love to get your code contributions to enable this. |
Hey, I developed a toolkit just for that that utilizes eBPF and is tested on various use cases, Including runtime RCE. It is actually MITM between the interpreter and the kernel, and it is able to log and stop/kill the process in case of violation. |
that translates to:
And compiled into an eBPF program using bpftrace. Everything can be done using secimport's CLI |
Very cool! How does one generate an accurate allow-list? |
FWIW this in my eyes seems integral when actually applying this package to a codebase. In reality, I may determine that it is OK for a particular dependency to e.g. make network calls, given the problem that it sets out to solve. Or I may determine that a particular dependency's "old/abandoned" status is OK, but may still care about it otherwise. |
Describe the solution you'd like
I would like the ability to control/tune the audit alerts at a package level.
Additional context
By placing a packj.yaml file at project level, I would like the ability to have a global set of audit alert config and then be able to override this for a particular package. This means we still get full audit alerting but can silence or tune the values for a package we have reviewed and trust. I guess this would need to be for a version or hash incase and updated version becomes malicious.
The text was updated successfully, but these errors were encountered: