path-wildcards: anchored trailing-* + per-endpoint port + R0040 args

[entlein]

Overview

• ap.was_path_opened_with_suffix/prefix: in pass-through mode, only
  scan Values (concrete paths). Wildcard Patterns are delegated
  to CompareDynamic rather than raw strings.HasPrefix/HasSuffix —
  a wildcard pattern can't safely answer a suffix/prefix question
  without dynamic matching.
• New R0040 rule helper ap.was_executed_with_args: returns true
  when the profile contains an entry whose Path matches AND whose
  Args vector matches (literal-equality, ⋯ one-position
  wildcard, or * zero-or-more trailing tokens).

Summary by CodeRabbit

• New Features
  • Wildcard-aware application-profile exec matching with per-path argument-vector anchoring.
  • Exec argv vectors are now projected per exec path to enable accurate runtime arg matching.
• Bug Fixes
  • Reduced false positives for was_executed_with_args by enforcing path/argv constraints when projected exec data is present, while preserving back-compat behavior when it’s absent.
  • File open suffix/prefix checks no longer evaluate wildcard patterns in pass-through mode (values only).
• Tests
  • Added unit tests for execs-by-path projection/matching (including wildcard cases) and expanded component coverage with Test_27_ApplicationProfileOpens.
• Chores
  • Upgraded Go dependencies.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

This PR extends ApplicationProfile-based CEL rule evaluation by adding per-path exec-argument projection, implementing argument-aware matching in CEL with wildcard support, refining open-path pattern handling to avoid false negatives, and validating the changes with comprehensive end-to-end component tests using new Kubernetes test workloads.

Changes

ApplicationProfile CEL Rule Evaluation Improvements

Layer / File(s)	Summary
Dependency version updates go.mod	Direct and indirect dependency versions are bumped for kubescape/storage, anchore/syft, logrus, sqlite, and containerd/docker ecosystems. A replace directive pins opencontainers/runtime-spec to v1.2.1.
Exec-by-path projection foundation pkg/objectcache/projection_types.go, pkg/objectcache/containerprofilecache/projection_apply.go, pkg/objectcache/containerprofilecache/projection_apply_test.go, pkg/objectcache/v1/mock.go	RuleProjectionSpec gains ExecsByPath field to store per-Path argv vectors; extractExecsByPath builds the mapping from cp.Spec.Execs, appending multiple argv lists for the same path, cloning slices to avoid aliasing, and representing nil Args as non-nil empty slices. Tests verify correct append semantics, cloning, and nil-vs-empty handling. Mock projection updated to populate ExecsByPath for test usage.
Exec args wildcard matching in CEL evaluation pkg/rulemanager/cel/libraries/applicationprofile/exec.go, pkg/rulemanager/cel/libraries/applicationprofile/exec_test.go	wasExecutedWithArgs now parses and validates runtime args from CEL, consults ExecsByPath for matching via CompareExecArgs (supporting ⋯ single-position and * zero-or-more wildcards), and implements back-compat fallback for absent ExecsByPath entries. Test expectations updated to enforce anchored argv matching and new TestExecWithArgsWildcardInProfile validates wildcard semantics.
Open-path pattern matching refinement pkg/rulemanager/cel/libraries/applicationprofile/open.go, pkg/rulemanager/cel/libraries/applicationprofile/open_test.go	wasPathOpenedWithSuffix and wasPathOpenedWithPrefix now scan only cp.Opens.Values when cp.Opens.All=true, avoiding false negatives from wildcard-shaped patterns; doc comment clarifies wasPathOpenedWithFlags parses but does not use flags for matching. New tests verify patterns are ignored in pass-through mode; flags-based tests refactored to separate path-only and flags-inclusive evaluation.
Component test for ApplicationProfile Opens matching tests/component_test.go, tests/resources/curl-user-profile-wildcards-deployment.yaml, tests/resources/nginx-user-profile-deployment.yaml, .github/workflows/component-tests.yaml	Test_27_ApplicationProfileOpens validates R0002 rule against recorded nginx profiles (asserting absolute paths only) and user-defined curl profiles with exact/wildcard/dynamic-segment Opens patterns. Includes helpers to deploy profiles, exec cat, poll alerts, and verify alert presence/absence per test case. Two test workload deployments added and test matrix updated.

Sequence Diagram(s)

sequenceDiagram
  participant CEL as CEL Runtime
  participant wasExec as wasExecutedWithArgs
  participant Cache as Profile Cache
  participant Matcher as CompareExecArgs
  CEL->>wasExec: path, runtime args
  wasExec->>Cache: load projected container profile
  wasExec->>Cache: lookup ExecsByPath[path]
  Cache-->>wasExec: projected argv vectors or nil
  alt ExecsByPath present (constraint mode)
    wasExec->>Matcher: compare runtime args vs profile args
    Matcher-->>wasExec: match result with wildcard support
  else ExecsByPath absent (back-compat)
    wasExec-->>CEL: match any runtime args if path exists
  end
  wasExec-->>CEL: true or false

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• kubescape/node-agent#799: Both PRs extend the rule-aware projected profile pipeline by updating the same ApplicationProfile exec CEL logic and the underlying container-profile projection model—implement Rule-Aware Profile Projection #799 moves exec checks onto projected data, and this main PR further refines it by projecting ExecsByPath (derived from cp.Spec.Execs) and using it in wasExecutedWithArgs to enforce anchored/wildcard argv-vector matching.
• kubescape/node-agent#788: Both PRs modify the ApplicationProfile CEL exec logic in pkg/rulemanager/cel/libraries/applicationprofile/exec.go—the related PR switches exec evaluation to use container profiles (cp.Spec.Execs), while the main PR extends wasExecutedWithArgs to project and match exec argv vectors via ExecsByPath.

Suggested labels

release

Suggested reviewers

• slashben

Poem

🐰 The args hop in, by path they're sorted,
Wildcards wildly, patterns contorted—
Opens pared down to concrete lights,
CEL now matches with clearer rights.
🥕 Projection hopped and tests took flight!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 40.91% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'path-wildcards: anchored trailing-* + per-endpoint port + R0040 args' clearly summarizes the main changes: wildcard path handling improvements and the new R0040 args feature, directly matching the changeset's core objectives.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

Tools execution failed with the following error:

Failed to run tools: 13 INTERNAL: Received RST_STREAM with code 2 (Internal server error)

Warning

Review ran into problems

🔥 Problems

Stopped waiting for pipeline failures after 30000ms. One of your pipelines takes longer than our 30000ms fetch window to run, so review may not consider pipeline-failure results for inline comments if any failures occurred after the fetch window. Increase the timeout if you want to wait longer or run a @coderabbit review after the pipeline has finished.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[entlein]

@CodeRabbit review this please together with kubescape/storage#323

[coderabbitai]

🧩 Analysis chain

---

🏁 Script executed:

#!/bin/bash
# Fetch details of the linked storage PR
gh pr view 323 --repo kubescape/storage --json title,body,files,additions,deletions,changedFiles
echo "---FILES---"
gh pr diff 323 --repo kubescape/storage

Length of output: 143814

---

🏁 Script executed:

#!/bin/bash
# Fetch node-agent PR `#807` diff
gh pr diff 807 --repo kubescape/node-agent
echo "---PR META---"
gh pr view 807 --repo kubescape/node-agent --json title,body,files,additions,deletions,changedFiles

Length of output: 28898

---

🏁 Script executed:

#!/bin/bash
# Check if CompareExecArgs exists in the storage repo
gh api repos/kubescape/storage/git/trees/main?recursive=1 | jq -r '.tree[].path' | grep -i "compareexec\|compare_exec\|execargs"
echo "---SEARCH CODE---"
# Search for CompareExecArgs in storage repo via code search
gh api "search/code?q=CompareExecArgs+repo:kubescape/storage&per_page=10" | jq -r '.items[].path'

Length of output: 18

---

🏁 Script executed:

#!/bin/bash
# Get the head branch of storage PR `#323`
gh pr view 323 --repo kubescape/storage --json headRefName,headRefOid
echo "---SEARCH BRANCH---"
# Search for CompareExecArgs on the PR `#323` branch
gh api "repos/kubescape/storage/contents/pkg/registry/file/dynamicpathdetector" \
  --jq '.[].name' 2>/dev/null || echo "API failed"
echo "---FILE LIST ON BRANCH---"
gh api "repos/kubescape/storage/git/refs/heads" | jq -r '.[].ref' | head -20
echo "---NODE-AGENT BRANCH---"
gh pr view 807 --repo kubescape/node-agent --json headRefName,headRefOid
echo "---SEARCH NODE-AGENT BRANCH---"
# Check if CompareExecArgs is defined locally in the node-agent repo
gh api "search/code?q=CompareExecArgs+repo:kubescape/node-agent&per_page=10" | jq -r '.items[].path'

Length of output: 1010

---

🏁 Script executed:

#!/bin/bash
# Fetch the contents of utils.go from the storage PR branch
gh api "repos/kubescape/storage/contents/pkg/registry/file/dynamicpathdetector/utils.go?ref=upstream-pr/sbob-path-wildcards" \
  | jq -r '.content' | base64 -d

echo "---ANALYZER TAIL (search for CompareExecArgs)---"
# Check if CompareExecArgs appears in any file on the branch
gh api "repos/kubescape/storage/git/trees/upstream-pr%2Fsbob-path-wildcards?recursive=1" \
  | jq -r '.tree[].path' | xargs -I{} sh -c \
  'content=$(gh api "repos/kubescape/storage/contents/{}?ref=upstream-pr/sbob-path-wildcards" 2>/dev/null | jq -r ".content // empty" | base64 -d 2>/dev/null); echo "$content" | grep -l "CompareExecArgs" && echo "FOUND IN: {}"' 2>/dev/null | grep "FOUND IN" || true

echo "---DIRECT GREP via search---"
gh api "search/code?q=CompareExecArgs+repo:kubescape/storage+ref:upstream-pr/sbob-path-wildcards" 2>/dev/null | jq -r '.total_count, (.items[].path)' || echo "search API does not filter by ref"

Length of output: 241

---

🏁 Script executed:

#!/bin/bash
# Try to get the diff more specifically for utils.go in storage PR `#323` 
gh pr diff 323 --repo kubescape/storage -- "*.go" 2>/dev/null | grep -A 30 "CompareExecArgs" || echo "Not found in storage PR diff"

echo "---CHECK UTILS GO IN STORAGE MAIN---"
gh api "repos/kubescape/storage/contents/pkg/registry/file/dynamicpathdetector/utils.go" \
  2>/dev/null | jq -r '.content' | base64 -d || echo "utils.go not in main"

echo "---CHECK EXEC ARGS IN STORAGE MAIN ALL GO FILES---"
gh api "search/code?q=ExecArgs+repo:kubescape/storage&per_page=10" | jq -r '.total_count, (.items[] | .path + " -> " + .name)'

Length of output: 422

---

@entlein: Reviewed PR #807 (node-agent) together with kubescape/storage#323. Both are well-structured and the test coverage is extensive. Here are my findings, ordered by severity:

---

🔴 Critical — Build break

CompareExecArgs is not defined in kubescape/storage

exec.go calls dynamicpathdetector.CompareExecArgs(profileArgs, runtimeArgs) but this function does not exist anywhere in kubescape/storage — confirmed via code search against both main and storage PR #323's diff. This will cause a compilation failure in node-agent.

CompareExecArgs needs to be added to storage PR #323. Based on the exec-test cases (literal equality, ⋯ single-position wildcard, * zero-or-more trailing tokens), it should mirror compareSegments from the rewritten CompareDynamic, but operating on a []string argument vector rather than a /-split path:

// CompareExecArgs reports whether runtimeArgs is matched by profileArgs.
// profileArgs may contain DynamicIdentifier (⋯, matches exactly one arg)
// or WildcardIdentifier (*, matches zero-or-more trailing args).
func CompareExecArgs(profileArgs, runtimeArgs []string) bool {
    return compareSegments(profileArgs, runtimeArgs)
}

The existing compareSegments in analyzer.go already implements this logic generically over []string. Exposing a thin public wrapper would avoid duplication.

Additionally, the comment in exec_test.go references the wrong repository — it should reference kubescape/storage#323, not k8sstormcenter/storage#23:

// dynamicpathdetector.CompareExecArgs (added in
// k8sstormcenter/storage#23 — ...   ← should be kubescape/storage#323

---

🟡 Medium — Missing test coverage

was_path_opened_with_flags function loses all direct tests

open_test.go removes TestOpenWithFlagsInProfile, TestOpenWithFlagsNoProfile, and TestOpenWithFlagsCompilation without replacement. The wasPathOpenedWithFlags function is still present in open.go (and even gains a new doc comment in this PR), but now has zero test coverage. If the flags argument is ever wired up in a future spec revision, there will be no baseline to diff against.

Consider retaining at least the compilation test and the no-profile guard test.

---

🟡 Medium — Misleading PR description / silent false-negatives

Patterns are skipped entirely, not "delegated to CompareDynamic"

The PR description states:

Wildcard Patterns are delegated to CompareDynamic rather than raw strings.HasPrefix/HasSuffix

But the actual change in open.go removes the Patterns loop entirely — patterns don't contribute at all to suffix/prefix answers in pass-through mode, regardless of whether CompareDynamic would match. This is the correct conservative fix (you can't answer "ends with .log?" by running CompareDynamic without a concrete candidate), but the description should be updated to say "Patterns are excluded from suffix/prefix scanning in pass-through mode" to avoid confusion for future rule authors who wonder why a profiled path that was collapsed to ⋯ doesn't surface in a suffix query.

---

🔵 Low — Subtle back-compat semantics in wasExecutedWithArgs

In exec.go, both the exact-path and pattern branches return true unconditionally when cp.ExecsByPath[path] is absent:

} else {
    // No ExecsByPath entry for this path — back-compat: treat as
    // "no argv constraint", match.
    return types.Bool(true)
}

This means: any profile built before ExecsByPath projection was active gets unconditional path-only matching, silently ignoring runtimeArgs. While intentional, this creates an invisible two-tier behavior: new profiles enforce arg constraints, old profiles don't. Rule authors writing R0040 expressions may be surprised when a newly-deployed workload with the same path suddenly starts enforcing args that the legacy profile never evaluated. A log-level warning ("back-compat: ExecsByPath absent for %s, matching on path only") would make the fallback observable.

---

🔵 Low — Storage PR #323 notes

removeEndpoint mutates the backing array in-place (append(s[:i], s[i+1:]...) in MergeDuplicateEndpoints). This is safe because the return value is immediately reassigned, but it's the kind of subtle slice mutation that trips up future readers. A short comment clarifying this intent would help.

effectiveThreshold and FindConfigForPath tiebreak parity: Both correctly use strict > (first entry wins on equal-length prefixes). The comment in effectiveThreshold rightly warns about this, but NewPathAnalyzerWithConfigs could deduplicate or log a warning on duplicate prefixes at construction time to surface misconfiguration earlier.

consolidateOpens quadratic worst-case: The outer loop is O(literals) × O(patterns), and each CompareDynamic call with mid-path * can backtrack O(segment²). This is fine for realistic filesystem profiles but worth noting in the function doc for operators tuning CollapseConfig thresholds for very wide trees.

---

Summary

Issue	Location	Severity
CompareExecArgs missing from kubescape/storage	exec.go + storage PR #323	🔴 Build break
Stale comment k8sstormcenter/storage#23	exec_test.go	🔵
was_path_opened_with_flags loses all test coverage	open_test.go	🟡
PR description misleads on pattern delegation	open.go	🟡
Back-compat silent tier in wasExecutedWithArgs	exec.go	🔵
removeEndpoint in-place mutation undocumented	analyze_endpoints.go	🔵

The storage PR #323 changes are solid — the per-port endpoint isolation, CompareDynamic rewrite with proper trailing-* anchoring, consolidateOpens, bufPool, and the extensive test suite all look correct. The node-agent changes are also logically sound, contingent on resolving the missing CompareExecArgs definition.

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[entlein]

@coderabbitai review

Collective re-review request after applying your atomic-split advisory + rabbit-feedback fixes across the full SBOB upstream PR set. Each PR is now scoped to a single tier per your dependency map:

Tier 0 (opens):

• path-wildcards: anchored trailing-* + per-endpoint port + R0040 args storage#323 (path-wildcards core: anchored trailing-*, per-port key, WildcardIdentifier + CollapseConfig API — squash per your "merge first / or squash together" note)
• feat(cel): was_path_opened* CEL helpers in applicationprofile library #811 (was_path_opened* CEL helpers — NEW)

Tier 2 (execs):

• allowing wildcards in exec args storage#322 (CompareExecArgs)
• profile-compaction: CollapseConfig CRD + projection overlay + user-maged lifecycle storage#325 (CollapseConfig CRD + processors)
• allowing wildcards in exec args #805 (resolveExecPath + 3-arg parse)
• path-wildcards: anchored trailing-* + per-endpoint port + R0040 args #807 (R0040 args consumer)
• feat(projection): add ExecsByPath composite-key surface to ProjectedContainerProfile #812 (ExecsByPath composite-key surface — NEW)

Tier 3 (network):

• allowing CIDRs, wildcards and Plural in IP and DNS storage#324 (networkmatch package)
• allowing CIDRs, wildcards and Plural in IP and DNS #806 (network wildcards CEL)

Tier 4 (tamper/sign):

• profile-compaction: CollapseConfig CRD + projection overlay + user-ma… #808 (projection overlay + tamper + non-blocking fanout + NN resource)
• sign and detect tampering #809 (cosign sign/verify + tamper detection)

Umbrellas:

• SBOB wildcards: DNS + IP + path exec wildcards, sign/tamper  storage#326
• SBOB wildcards: DNS + IP + path exec wildcards, sign/tamper  #810

Please confirm atomicity per your earlier advisory and flag any remaining cross-PR coupling we missed.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

I'll fetch all PRs in the set to verify atomicity and cross-PR coupling.

---

🏁 Script executed:

#!/bin/bash
set -e

# Fetch metadata for all storage PRs
for pr in 322 323 324 325 326; do
  echo "===STORAGE PR $pr==="
  gh pr view $pr --repo kubescape/storage --json title,state,headRefName,baseRefName,additions,deletions,changedFiles 2>/dev/null || echo "NOT FOUND"
done

# Fetch metadata for all node-agent PRs
for pr in 805 806 807 808 809 810 811 812; do
  echo "===NODE-AGENT PR $pr==="
  gh pr view $pr --repo kubescape/node-agent --json title,state,headRefName,baseRefName,additions,deletions,changedFiles 2>/dev/null || echo "NOT FOUND"
done

Length of output: 2908

---

🏁 Script executed:

#!/bin/bash
# Fetch diffs for storage PRs
for pr in 322 323 324 325 326; do
  echo "===STORAGE DIFF $pr==="
  gh pr diff $pr --repo kubescape/storage 2>/dev/null | head -600 || echo "DIFF FAILED"
  echo "---END STORAGE $pr---"
done

Length of output: 101307

---

🏁 Script executed:

#!/bin/bash
# Fetch diffs for node-agent PRs (excluding `#807` which we already have)
for pr in 805 806 808 809 810 811 812; do
  echo "===NODE-AGENT DIFF $pr==="
  gh pr diff $pr --repo kubescape/node-agent 2>/dev/null | head -500 || echo "DIFF FAILED"
  echo "---END NODE-AGENT $pr---"
done

Length of output: 93396

---

@entlein: Good progress on the split. After inspecting all 13 diffs in detail, here is the atomicity verdict and the remaining coupling issues that need resolution before merge ordering can be safely established.

---

✅ Confirmed Atomic (no cross-PR coupling issues found)

PR	Verdict
kubescape/storage#322	✅ Self-contained — CompareExecArgs + tests, no overlap with other PRs
#805	✅ Self-contained — busybox-symlink resolveExecPath + 3-arg CEL overload
#809	✅ Self-contained — cmd/sign-object CLI, no runtime entanglement
#811	✅ Self-contained — removes Patterns loop from wasPathOpenedWithSuffix/Prefix + doc comments

---

🔴 Remaining Cross-PR Coupling (must resolve before merging)

1 — storage#324 ↔ storage#325: protobuf test cannot pass without the sibling

storage#324 adds NetworkNeighbor.IPAddresses []string to the struct and a TestNetworkNeighbor_IPAddresses_ProtobufRoundtrip test that calls Marshal() / Unmarshal().

storage#325's generated.pb.go is where the encoding of that field actually lives (tag 0x4a = field 9, inside NetworkNeighbor.MarshalToSizedBuffer and the corresponding Size() / Unmarshal() paths). The roundtrip test in #324 will fail to compile and run on its own because the generated protobuf code for the field is in #325.

Fix options:

• Option A (preferred): Move the IPAddresses protobuf encoding from generated.pb.go in storage#325 into storage#324 so the test and the encoding ship in the same PR.
• Option B: Mark #324 as depending on #325 and merge them atomically in CI (same release train).

---

2 — node-agent#808 ↔ node-agent#812: extractExecsByPath is defined in both

node-agent#812 adds ExecsByPath map[string][]string to ProjectedContainerProfile (in projection_types.go) and adds extractExecsByPath to projection_apply.go.

node-agent#808 also adds an identical extractExecsByPath to projection_apply.go and calls pcp.ExecsByPath = extractExecsByPath(cp).

If #812 merges first (which it must, since #807 reads cp.ExecsByPath), #808 will hit a direct merge conflict on the same function in the same file.

Fix: Rebase #808 on top of #812 and remove its copy of extractExecsByPath. After the rebase, #808 only needs the pcp.ExecsByPath = extractExecsByPath(cp) call line — the function definition is already present from #812.

---

3 — node-agent#806 (Tier 3) depends on node-agent#808 (Tier 4)

node-agent#806's matchIPField routes wildcard IP entries (CIDRs, *) to field.Patterns and calls networkmatch.MatchIP(field.Patterns, observed). For field.Patterns to contain anything, extractEgressAddresses / extractIngressAddresses must append n.IPAddresses... — and that append is in node-agent#808's projection_apply.go, not in #806 itself.

Without #808 merged first, a profile entry with e.g. IPAddresses: ["10.0.0.0/8"] will never reach Patterns, so matchIPField will always fall through to a miss for CIDR-only entries. Tier 3 silently degrades without Tier 4 being present.

Fix: Promote the extractEgressAddresses / extractIngressAddresses n.IPAddresses... append into node-agent#806 (it logically belongs with the network-wildcard CEL work), and remove it from #808 after rebasing. This restores the Tier 3-before-Tier 4 ordering the map intends.

---

4 — go.mod downgrades exist only in the umbrella (storage#326)

storage#326 has three dependency version changes absent from all atomic tier PRs:

github.com/anchore/syft         v1.42.3 → v1.32.0
github.com/anchore/stereoscope  v0.1.22 → v0.1.9
github.com/opencontainers/runtime-spec v1.3.0 → v1.2.1

If the tier PRs (#322–#325) are merged individually against main, they will carry syft v1.42.3. The umbrella then merges them all and applies the downgrades. This means the umbrella cannot be trivially assembled from its tier PRs — the umbrella is doing real independent work (the dependency pin). Either:

• Add a thin go.mod-only PR (no code changes) that must land before #326, or
• Move the downgrades into whichever tier PR first introduces the dependency (likely storage#323 or storage#324 if networkmatch pulls in syft transitively).

---

⚠️ Minor / Cosmetic

Item	Location
storage#323 title still says "R0040 args"	That scope moved to node-agent#807; update the title
node-agent#808 still bundles 4 concerns	stampOverlayIdentity, tamper detection, IPAddresses extraction, isNetworkIPWildcard/DNS classifiers — acceptable if you want a single Tier 4 PR, but worth noting for future bisect

---

Revised Merge Ordering (after fixes)

graph TD
  S322["storage#322\nCompareExecArgs"] --> NA807["node-agent#807\nR0040 args"]
  S323["storage#323\npath-wildcards core"] --> NA811["node-agent#811\nwas_path_opened*"]
  S323 --> S325["storage#325\nCollapseConfig CRD"]
  S324["storage#324 + IPAddresses pb\nnetworkmatch"] --> NA806["node-agent#806\nnetwork CEL"]
  S324 --> NA808["node-agent#808\nprojection overlay + tamper"]
  S325 --> NA808
  NA812["node-agent#812\nExecsByPath surface"] --> NA807
  NA812 --> NA808
  NA805["node-agent#805\nresolveExecPath"] --> NA807
  NA808 --> NA806
  NA808 --> S326["storage#326 umbrella"]
  NA810["node-agent#810 umbrella"] --> S326

Loading

[matthyx]

Blocking: this branch still does not build against current main. Running go test ./pkg/rulemanager/cel/libraries/applicationprofile/... fails in pkg/rulemanager/cel/libraries/applicationprofile/exec.go because the new wasExecutedWithArgs path references cp.ExecsByPath and dynamicpathdetector.CompareExecArgs, but neither symbol exists in this branch's current dependency state (ProjectedContainerProfile has no ExecsByPath, and storage v0.0.258 has no CompareExecArgs). As-is this PR is not mergeable on its own; it needs to be explicitly rebased onto the stacked changes that introduce those symbols, or the new calls need to be gated/removed here.

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (3)

pkg/rulemanager/cel/libraries/applicationprofile/open_test.go (1)

117-122: ⚡ Quick win

Keep direct coverage for ap.was_path_opened_with_flags.

These edits convert the old flag-focused cases into ap.was_path_opened(...), so wasPathOpenedWithFlags no longer has a test for its remaining contract: CEL list parsing and malformed-flags rejection. Please keep at least one happy-path case and one invalid-flags case here.

Also applies to: 186-205, 210-241

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pkg/rulemanager/cel/libraries/applicationprofile/open_test.go` around lines
117 - 122, Restore direct coverage for ap.was_path_opened_with_flags in
TestOpenInProfile by adding at least two cases: one happy-path where the CEL
list of flags parses correctly and the function returns true (e.g., supply a
valid flags list and expected open event), and one invalid-flags case where a
malformed flags CEL list causes the function to reject the input (assert an
error or false per contract). Locate the test table or assertions around
TestOpenInProfile and reintroduce cases that call ap.was_path_opened_with_flags
(not ap.was_path_opened) so you exercise CEL list parsing and malformed-`flags`
rejection behavior; keep the existing ap.was_path_opened cases as well.

go.mod (1)

474-474: Supply chain and merge coordination risk.

Using a fork (k8sstormcenter/storage) instead of the canonical kubescape/storage introduces supply chain concerns and requires careful coordination:

• Provenance: Verify that the fork maintainer is trustworthy and the fork accurately cherry-picks only the needed CompareExecArgs changes
• Atomicity: Ensure this replace directive is removed in the same release cycle that upgrades to the official storage version containing the fix
• Drift risk: The fork may diverge from upstream, introducing subtle behavioral differences

Consider these alternatives to reduce risk:

1. Feature gating: Guard the new ExecsByPath / CompareExecArgs calls behind a feature flag until storage PR #323 ships
2. Atomic merge: Coordinate merging this PR simultaneously with storage PR #323 to avoid the fork entirely
3. Tracking issue: Create a GitHub issue to track removal of this replace directive, linked to storage PR #323 closure

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@go.mod` at line 474, The go.mod replace directive pointing at
github.com/k8sstormcenter/storage (replacing github.com/kubescape/storage)
creates supply-chain and merge coordination risk; either remove this replace and
coordinate merging with the upstream storage PR `#323` so the official module
contains CompareExecArgs/ExecsByPath, or gate uses of the new APIs
(ExecsByPath/CompareExecArgs) behind a feature flag until upstream lands, and
add a tracking GitHub issue to remove the go.mod replace as soon as storage PR
`#323` is merged; ensure the replace removal is done atomically with the upgrade
to the official release to avoid drift.

pkg/rulemanager/cel/libraries/applicationprofile/exec.go (1)

127-130: ⚡ Quick win

Add visibility when legacy profiles bypass argv constraints.

Line 127 and Line 140 return true when ExecsByPath lacks a key for a matched path. Add a warn/metric (ideally once per container/profile hash) so silent back-compat matches are observable.

Also applies to: 140-142

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pkg/rulemanager/cel/libraries/applicationprofile/exec.go` around lines 127 -
130, The branch that returns types.Bool(true) when ExecsByPath lacks a key for a
matched path (the legacy "no argv constraint" back-compat in the ExecsByPath
handling) should emit an observable signal so these silent matches are visible;
update the code paths that currently return types.Bool(true) (the branches
referencing ExecsByPath) to log or increment a metric including the
container/profile hash and ensure the signal is emitted at most once per
container/profile by deduplicating with a short-lived in-memory cache or an
"emit-once" set keyed by containerID+profileHash; apply the same change to both
places where types.Bool(true) is returned so legacy bypasses are recorded.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@go.mod`:
- Line 474: Add a clear TODO comment immediately above the replace directive
"replace github.com/kubescape/storage => github.com/k8sstormcenter/storage
v0.0.240-0.20260527160734-5e39d0018391" explaining this is a temporary override,
referencing the upstream storage PR (`#323`), the criteria for removal (e.g., when
that PR is merged and a released version is available), and include the
author/date or ticket that added the workaround so it can be tracked and removed
later.

In `@pkg/rulemanager/cel/libraries/applicationprofile/exec_test.go`:
- Around line 317-318: Update the test comment in exec_test.go that references
the old storage repo; replace the text "k8sstormcenter/storage#23" with the
correct "kubescape/storage#23" (locate the comment block in
pkg/rulemanager/cel/libraries/applicationprofile/exec_test.go where the matcher
note appears) so the PR link points to the correct repository.

---

Nitpick comments:
In `@go.mod`:
- Line 474: The go.mod replace directive pointing at
github.com/k8sstormcenter/storage (replacing github.com/kubescape/storage)
creates supply-chain and merge coordination risk; either remove this replace and
coordinate merging with the upstream storage PR `#323` so the official module
contains CompareExecArgs/ExecsByPath, or gate uses of the new APIs
(ExecsByPath/CompareExecArgs) behind a feature flag until upstream lands, and
add a tracking GitHub issue to remove the go.mod replace as soon as storage PR
`#323` is merged; ensure the replace removal is done atomically with the upgrade
to the official release to avoid drift.

In `@pkg/rulemanager/cel/libraries/applicationprofile/exec.go`:
- Around line 127-130: The branch that returns types.Bool(true) when ExecsByPath
lacks a key for a matched path (the legacy "no argv constraint" back-compat in
the ExecsByPath handling) should emit an observable signal so these silent
matches are visible; update the code paths that currently return
types.Bool(true) (the branches referencing ExecsByPath) to log or increment a
metric including the container/profile hash and ensure the signal is emitted at
most once per container/profile by deduplicating with a short-lived in-memory
cache or an "emit-once" set keyed by containerID+profileHash; apply the same
change to both places where types.Bool(true) is returned so legacy bypasses are
recorded.

In `@pkg/rulemanager/cel/libraries/applicationprofile/open_test.go`:
- Around line 117-122: Restore direct coverage for ap.was_path_opened_with_flags
in TestOpenInProfile by adding at least two cases: one happy-path where the CEL
list of flags parses correctly and the function returns true (e.g., supply a
valid flags list and expected open event), and one invalid-flags case where a
malformed flags CEL list causes the function to reject the input (assert an
error or false per contract). Locate the test table or assertions around
TestOpenInProfile and reintroduce cases that call ap.was_path_opened_with_flags
(not ap.was_path_opened) so you exercise CEL list parsing and malformed-`flags`
rejection behavior; keep the existing ap.was_path_opened cases as well.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 13925bf1-e737-4b6b-a4c1-a13450f2d4a9

📥 Commits

Reviewing files that changed from the base of the PR and between a9bde81 and ce0d6a4.

⛔ Files ignored due to path filters (1)

• go.sum is excluded by !**/*.sum

📒 Files selected for processing (8)

• go.mod
• pkg/objectcache/containerprofilecache/projection_apply.go
• pkg/objectcache/containerprofilecache/projection_apply_test.go
• pkg/objectcache/projection_types.go
• pkg/rulemanager/cel/libraries/applicationprofile/exec.go
• pkg/rulemanager/cel/libraries/applicationprofile/exec_test.go
• pkg/rulemanager/cel/libraries/applicationprofile/open.go
• pkg/rulemanager/cel/libraries/applicationprofile/open_test.go

[matthyx]

Re-checked this at the current HEAD (9c89feb). The old missing-symbol blocker is fixed, but I still see three blocker-level issues:

1. tests/component_test.go now contains a second //go:build component, a second package tests, a second import block, and a duplicated Test_32_UnexpectedProcessArguments body. gofmt -e tests/component_test.go fails with parse errors at 1574, 1576, 4978, and 5206, so the component test file does not parse.
2. The new storage replace in go.mod is not readonly-clean. go test -mod=readonly ./pkg/objectcache/containerprofilecache fails immediately with go: updates to go.mod needed; to update it: go mod tidy, so clean/reproducible CI runs fail before tests even start.
3. pkg/objectcache/containerprofilecache/projection_apply.go / pkg/rulemanager/cel/libraries/applicationprofile/exec.go: ExecsByPath is keyed only by path, so duplicate ExecCalls collapse to the last argv shape. That breaks merged profiles that legitimately append multiple allowed argv variants for the same executable path (mergeApplicationProfile appends matched.Execs), and ap.was_executed_with_args(...) will reject valid executions unless they match the final entry.

[entlein]

@claude test this again please using the same upstream-mirror image, please

[entlein]

Re-running on current HEAD `e5069fd6` (the rebase tip — 10 new commits since this morning's run on `90465661`), reusing the same storage image `ghcr.io/k8sstormcenter/storage:regress-v0.0.278-20260529-081531` per your ask. NA build: https://github.com/k8sstormcenter/node-agent/actions/runs/26629665648.

CT will auto-chain after build completes (same shared tag on both images, so the deploy sees a coherent pair). Will report the matrix outcome.

[entlein]

Retry result on rebased tip `e5069fd6` (reused storage `regress-v0.0.278-20260529-081531`): 21/21 GREEN ✓ (run 26629884873).

Same result as this morning's pre-rebase run — the rebase didn't introduce regressions. Full pass list unchanged (Test_01, 02, 06–08, 10–24, 27).

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/resources/nginx-user-profile-deployment.yaml`:
- Line 20: The nginx image version nginx:1.14.2 in the
nginx-user-profile-deployment.yaml file is outdated and affected by known
security vulnerabilities. Either update the image to a current stable version
such as nginx:1.28, or if this specific version is intentionally pinned for the
test scenario, add a comment above the image line documenting the reason why
this particular version is required for test reproducibility.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e332298d-423b-478e-860d-92545216f6f9

📥 Commits

Reviewing files that changed from the base of the PR and between b27f8bc and c5dd143.

⛔ Files ignored due to path filters (1)

• go.sum is excluded by !**/*.sum

📒 Files selected for processing (13)

• .github/workflows/component-tests.yaml
• go.mod
• pkg/objectcache/containerprofilecache/projection_apply.go
• pkg/objectcache/containerprofilecache/projection_apply_test.go
• pkg/objectcache/projection_types.go
• pkg/objectcache/v1/mock.go
• pkg/rulemanager/cel/libraries/applicationprofile/exec.go
• pkg/rulemanager/cel/libraries/applicationprofile/exec_test.go
• pkg/rulemanager/cel/libraries/applicationprofile/open.go
• pkg/rulemanager/cel/libraries/applicationprofile/open_test.go
• tests/component_test.go
• tests/resources/curl-user-profile-wildcards-deployment.yaml
• tests/resources/nginx-user-profile-deployment.yaml

🚧 Files skipped from review as they are similar to previous changes (11)

• .github/workflows/component-tests.yaml
• pkg/rulemanager/cel/libraries/applicationprofile/open.go
• tests/resources/curl-user-profile-wildcards-deployment.yaml
• pkg/rulemanager/cel/libraries/applicationprofile/exec_test.go
• pkg/objectcache/projection_types.go
• pkg/objectcache/v1/mock.go
• pkg/rulemanager/cel/libraries/applicationprofile/exec.go
• tests/component_test.go
• pkg/objectcache/containerprofilecache/projection_apply_test.go
• go.mod
• pkg/rulemanager/cel/libraries/applicationprofile/open_test.go

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Check nginx:1.14.2 for security advisories and compare with latest version.

# Check for security vulnerabilities in nginx:1.14.2
echo "=== Checking for vulnerabilities in nginx:1.14.2 ==="
gh api graphql -f query='
{
  securityVulnerabilities(first: 10, ecosystem: ACTIONS, package: "nginx", orderBy: {field: UPDATED_AT, direction: DESC}) {
    nodes {
      advisory {
        summary
        severity
        publishedAt
      }
      vulnerableVersionRange
      firstPatchedVersion {
        identifier
      }
    }
  }
}'

# Get latest nginx version from Docker Hub
echo -e "\n=== Latest nginx versions on Docker Hub ==="
curl -s 'https://registry.hub.docker.com/v2/repositories/library/nginx/tags?page_size=5&ordering=last_updated' | jq -r '.results[] | "\(.name) - updated: \(.last_updated)"'

Repository: kubescape/node-agent

Length of output: 1992

---

🌐 Web query:

nginx 1.14.2 release date security vulnerabilities CVEs

💡 Result:

Nginx version 1.14.2 was released on December 4, 2018 [1][2][3]. Regarding security vulnerabilities, nginx 1.14.2 was a maintenance release that addressed several bug fixes and reliability improvements, rather than a security-focused release itself [1][3]. However, the release preceding it, version 1.14.1, contained critical security fixes [4]. Vulnerabilities often associated with this era of nginx (1.14.x series) include: - CVE-2018-16843: A vulnerability in the HTTP/2 implementation where a client could cause excessive memory consumption [4][5]. - CVE-2018-16844: A vulnerability in the HTTP/2 implementation where a client could cause excessive CPU usage [4][5]. - CVE-2018-16845: A memory disclosure vulnerability in the ngx_http_mp4_module, occurring when processing specially crafted mp4 files [4][5]. These issues were addressed in nginx 1.14.1 [4]. Users are advised that the 1.14.x branch is an end-of-life stable branch and is no longer supported [6]. To ensure security, it is recommended to upgrade to a currently supported stable or mainline version [6].

Citations:

• 1: http://mailman.nginx.org/pipermail/nginx-announce/2018/000225.html
• 2: http://nginx.org/en/CHANGES-1.14
• 3: https://mailman.nginx.org/pipermail/nginx-devel/2018-December/011681.html
• 4: https://osv.dev/vulnerability/openSUSE-SU-2019:0195-1
• 5: https://www.suse.com/support/update/announcement/2019/suse-su-20190334-1/
• 6: https://endoflife.date/nginx

---

🌐 Web query:

nginx latest stable version 2024 2025

💡 Result:

As of June 17, 2026, the NGINX project maintains its release history through distinct mainline and stable branches [1]. During 2024 and 2025, the following stable versions were the primary releases: For 2024, NGINX 1.26.0 was released as the stable version in April 2024, following the retirement of the 1.25.x branch [2][1]. For 2025, NGINX 1.28.0 was released as the new stable version on April 23, 2025, succeeding the 1.26.x stable branch [3][4][1]. Subsequent updates to the 1.28.x stable branch were released throughout the remainder of 2025 to incorporate critical bug fixes [3][5]. The NGINX versioning scheme uses even numbers for the stable branch (e.g., 1.26.x, 1.28.x) and odd numbers for the mainline branch (e.g., 1.27.x, 1.29.x) [1]. New stable branches are typically created by forking the current mainline branch every April [1].

Citations:

• 1: https://endoflife.date/nginx
• 2: https://nginx.org/en/CHANGES
• 3: https://nginx.org/2025.html
• 4: https://community.nginx.org/t/nginx-open-source-core-1-28-0-released-2025-04-23/4189
• 5: http://nginx.org/2025.html

---

🌐 Web query:

nginx 1.14.2 known vulnerabilities advisories

💡 Result:

NGINX 1.14.2 is a significantly outdated version released around 2018–2019 and is no longer supported [1]. It is susceptible to numerous security vulnerabilities discovered after its release [2][3][4]. Key vulnerabilities and security context for NGINX 1.14.2 include: 1. Notable Vulnerabilities: NGINX 1.14.2 is affected by several well-documented CVEs that were discovered during its operational lifetime or persist due to its age [2][4]. Examples include: - CVE-2021-3618: Related to ALPACA (Application Layer Protocol Content Confusion) attacks [2]. - CVE-2022-41741 & CVE-2022-41742: Vulnerabilities in the mp4 module, which can result in denial of service, memory disclosure, or arbitrary code execution when processing malformed mp4 files [2]. - Various legacy vulnerabilities: Depending on the specific build, it may also be subject to older issues such as CVE-2018-16843, CVE-2018-16844, and CVE-2018-16845 [1][5][6]. 2. Vulnerability Sources: Because 1.14.2 is end-of-life, general vulnerability databases (such as Snyk or Repology) will flag it as vulnerable to a wide array of CVEs discovered in the years since its release [7][8][4]. These vulnerabilities often stem not just from the NGINX core, but also from outdated dependencies included in older container images or packages [8]. 3. Security Recommendation: The official recommendation for any NGINX instance running version 1.14.2 is to upgrade to a supported, current stable version [1][2]. Using outdated web server software exposes systems to known, exploitable vulnerabilities that have been patched in modern releases [2][3]. You can monitor the official NGINX security advisories page for information on recent threats and fixed versions [1]. For detailed, environment-specific vulnerability reports, you should use a modern vulnerability scanner (like Trivy, Clair, or Snyk) against your specific deployment, as NGINX's security posture is often dependent on the specific modules enabled (e.g., ngx_http_mp4_module) and the underlying operating system libraries [2][8].

Citations:

• 1: http://nginx.org/en/security_advisories.html
• 2: https://www.debian.org/lts/security/dla-3203-1
• 3: https://www.cybersecurity-help.cz/vdb/soft/f5_networks/nginx/1.14.2/
• 4: https://repology.org/project/nginx/cves?version=1.14.2
• 5: https://osv.dev/vulnerability/SUSE-SU-2019:0334-1
• 6: https://www.suse.com/support/update/announcement/2019/suse-su-20190334-1/
• 7: https://repology.org/project/nginx/cves?version=1.14.2.1
• 8: https://snyk.io/test/docker/nginx:1.14.2

---

Update outdated nginx image version or document why this specific version is required.

The image nginx:1.14.2 (released December 2018) is end-of-life and affected by multiple known CVEs including CVE-2018-16843, CVE-2018-16844, CVE-2018-16845, CVE-2021-3618, and CVE-2022-41741/41742. While this is a test fixture and may use a pinned version intentionally for reproducibility, consider either upgrading to a current stable version (e.g., nginx:1.28 as of June 2026) or documenting the reason this specific version is required for the test scenario.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/resources/nginx-user-profile-deployment.yaml` at line 20, The nginx
image version nginx:1.14.2 in the nginx-user-profile-deployment.yaml file is
outdated and affected by known security vulnerabilities. Either update the image
to a current stable version such as nginx:1.28, or if this specific version is
intentionally pinned for the test scenario, add a comment above the image line
documenting the reason why this particular version is required for test
reproducibility.

[entlein]

Component tests: 21/21 passing ✅

Validated as the base of the exec-args stack: #805 rebased on top of this PR, with the storage side from kubescape/storage#328, on a coherent node-agent + storage image pair.

Full matrix green:
Test_01, 02, 06, 07, 08, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 32 — all pass.

[entlein]

Benchmark (stack context for #805): with #805 (exec-arg → storage move) rebased on top of this PR and kubescape/storage#328 deployed, node-agent memory drops ~20% vs this PR alone:

Metric	This PR (base)	+#805	Δ
Avg Memory (MiB)	331.0	261.2	−21.1%
Peak Memory (MiB)	333.7	269.5	−19.3%
Avg / Peak CPU	0.205 / 0.214	0.205 / 0.215	flat

This PR is the before-baseline of that comparison; storage held constant at #328. Quality gate passed.

[matthyx]

Re-checked at the current HEAD (c5dd143c). The earlier merge-conflict blocker is resolved, the branch now merges cleanly with main, and the focused checks I had been using for blocker verification are passing.