Boost ReadOnlyRootFilesystem rule score from 1 to 3

[arpitjain099]

What

Raises the ReadOnlyRootFilesystem rule score from Points: 1 to Points: 3.

Closes #572

Why

In #572 a maintainer agreed the rule is scored too low:

Yeah agreed, we can probably boost it.
Although I think running as non-root is probably a bigger deal as if your rootfs has sensible permissions most of that should be non-writable for you as non-root anyway, and if you have some other writable mount you'd still have somewhere to write with a readonly rootfs.

An immutable root filesystem is a real defense-in-depth control: it raises attacker cost by preventing malicious binaries from being written into PATH and makes it harder to stage post-exploitation tooling (linpeas, peirates, etc.) after gaining a shell, as called out in the issue thread.

Chosen value: 3 (not higher)

1 is the floor for a positive hardening rule, so it understates the control. I picked 3 because:

• It matches the other top positive container-hardening rules already in the ruleset (ServiceAccountName and ApparmorAny are both Points: 3), so the rule is now weighted alongside its peers rather than sitting at the floor.
• It deliberately stays at or below RunAsNonRoot's weight, honoring the maintainer's point that running as non-root is the bigger deal. RunAsNonRoot keeps Advise: 10 (the highest advisory weight), so it remains the more strongly recommended control.

This is a conservative, defensible boost rather than an arbitrary large bump.

Tests

• Updated the affected assertion in pkg/ruler/ruleset_test.go: the manifest combining readOnlyRootFilesystem: true with runAsNonRoot: true now totals 4 (3 + 1) instead of 2.
• Searched the repo for other hardcoded score totals involving this rule. The .bats integration assertions for read-only rootfs (score-1-dep-ro-root-fs.yml) use sign-based checks (assert_gt_zero_points) and the per-element ordering tests assert integer-and-descending, all of which still hold with the new value, so no .bats change is needed. The score-N-*.yml asset filenames are descriptive labels, not asserted totals.
• go build ./... and go test ./... both pass.

Before / after

A deployment whose only hardening is readOnlyRootFilesystem: true:

• before: score=1, ReadOnlyRootFilesystem points=1
• after: score=3, ReadOnlyRootFilesystem points=3

[arpitjain099]

Rebased onto master. The conflict was the NewRuleset refactor; re-applied the one change (ReadOnlyRootFilesystem Points 1 -> 3) on top of the new structure. Builds and the ruler tests pass.