These malicious npm packages often “phone home” during install or runtime, opening C2 channels, exfiltrating env vars, or beaconing quietly in the background. Static checks and SBOMs rarely catch that kind of dynamic behavior. With AI-generated or auto-installing code pipelines, that risk gets amplified since installs happen more often and less predictably. Watching what packages do at runtime feels like the next frontier here.
kernel state maps vs event buffering is an interesting choice. We've been seeing more in-memory malware in our CI/CD pipelines lately that never touches disk or network - any thoughts on extending this to userspace memory introspection?
Take a look at https://jibril.garnet.ai/readme/theory-behind so you have a better understanding what we are doing. As long as there is 'a resource' and 'an action', we can track it. Full memory (file-backed or not) introspection is tricky due to performance reasons (like checksumming files, picking entire content being read/write to pages, etc). Still, we would be able to do if we wanted (specially considering we can add uprobes on-demand for binaries being executed). Hope that helps.
Yes, its a one step integration into your workflow file, typically before the steps you want to monitor eg. build, test if you don't want to see everything happening in your runner host. It has worked pretty well with ubuntu-latest and stock Linux runners from GH out of the box.
