1. Feature isn't public yet, but currently we're able to block ingress/egress by IP + MASK and/or DOMAIN resolutions (meaning blocking the resolution itself, or anything that is resolved from or to example.com, synchronously while the resolution happens). This would be given as a setting (yaml?) to our CI action to be configured by the end user. L7 firewall is in our roadmap.
2. Leo is former falco creator (sysdig), I'm former tracee core developer (aqua). For CI/CD, performance isn't usually a concern, unless the "sidecar" is consuming all runner resources and causing latencies/jitterings/false-positives in functional tests (saying this because your comment about bad experiences with side cars, or eBPF agents).
3. I don't want to FUD but argus is currently consuming less than 10% resources when compared with other eBPF security tools around, with the same workload, and it does not miss events (not a single one don't matter what you do, without causing latencies to your code). Argus has a complete different architecture. You don't even need an userland agent running if that is mandatory (although it improves some available data). Userland code basically aggregates and report, almost no resource consumption.
4. Although argus performs so well, we're targeting it for CI/CD now, until something changes (never know), but all its infrastructure is ready for staging and production environments (same info and detection events).
5. About the threat model:
- Everything is a resource (namespace, user, group, task, socket, network flow, file).
- Resources suffer actions (different depending on the resource, files actions are heavily influenced by VFS operations like unlink, read, write, mmap, for example).
- All resources can be stored for further analysis (historical deduplicated data of all actions that have ever happened to each resource).
- Detections are built on top of this model: events are deduplicated and generated (or re-generated) only if the resource data has changed (like another action was taken on it).
Example: process opens a file that triggers a detection (under certain conditions). A detection event is generated with an unique deduplicated id. The process exits and know the "task" resource has a new info (exittime), so the event is sent again with updated info (but same unique key).
Putting all this together, our detections vary among Evasion, Brute Force, Credentials, Discovery, Drift, Escalation, Execution, Exfiltration, Lateral Move, Mining, Persistence, Tamper OS, Tamper Kernel, Tamper Argus, App Hooking, Kernel Hooking, Denial-of-Service, Offensive Tool, Informational. We're not mapping 1:1 with MITRE but some of our labels are a mix of couple (or sometimes 3) of MITRE classes.
I hope it answers your questions for now.