Other SecRel Vulnerabilities Carrying Over from Sprint Y

[nelsestu]

User Story

As OnCall Engineer, We Need SecRel to continue Passing on the develop branch. This sets us up for the best chances of maintaining a deployable state and LHDI's continuous ATO. Known vulnerabilities are expressed below:

<img width="1042" src="https://api.zenhub.com/attachedFiles/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBNkxrQlE9PSIsImV4cCI6bnVsbCwicHVyIjoiYmxvYl9pZCJ9fQ==--6e131a8ea1f32be635fae467d1dfd03114a181a7/db-init.png" alt="db-init.png" />

Acceptance Criteria

• Document the agreements reached with LHDI SecRel team regarding the use of global suppressions.
• Develop Branch Default SecRel Workflow is Passing for all images that we aim to deploy other.

Related Links

1. Recent SecRel Failure
2. Slack Thread

[nelsestu]

@BerniXiongA6 @meganhicks @lisac @msnwatson For additional context about the SecRel discussion starting in 10 minutes, the discussion relates back to this ticket. At the moment SecRel is passing due to a global suppression rule added by Jacob in an effort to unblock our deployments. My suspicion is that this rule is too open ended, and we'll discuss what a reasonable rule might look like. Hopefully Jacob agrees that a global rule is still necessary. The scope of work for this ticket is really dependent on what happens with this discussion. Jacob reenabled one of the global suppressions and we went from 60-70 vulnerabilities to zero. I don't actually know how widely this global rule suppresses. I know that without the rule in place, there were 60-70 vulnerabilities appearing. I am happy to continue to collaborate towards the resolution of any vulnerabilities that actually require mitigation. But we won't know what that list looks like until the conversation starting in just a few minutes.

[nelsestu]

We were able to confirm and clarify a number of points during our call with Jacob today. First, I want to confirm that yes, SecRel was/is passing, but it is passing due to a temporary catch all suppression rule that Jacob added for us on Friday. Only someone with Jacob's permissions can create suppression rules that ignore everything like the one that is allowing SecRel to pass. Jacob isn't going to leave this catch all suppression rule enabled permanently, because it is literally ignoring everything and anything Aqua surfaces. So what we confirmed on the call is that

• A) suppressing everything is something VRO can request if there is a temporary and urgent reason for doing so (ex: blocked deployments)
• B) assessors are ultimately held responsible for the suppressions they allow, and for that reason LHDI would never want to leave that level of suppression enabled permanently.
• C) Prior to Jacob adding this "catch all" suppression rule, I was seeing 70 or so non-remediated vulnerabilities appearing in SecRel runs. Reviewing these I could see that many of these seemed to be invalid/non-actionable, similar to the hundreds of "upgrade to debian 12.5" recommendations that we used to see.
• D) There were also valid vulnerabilities that VRO should remediate
• E) Jacob confirmed that he was working on creation of the subset of global rules that we could leave enabled long term. For these, he can target specific scenarios and apply those specifics using a tool that he built that provides the precision needed.

So this ticket was created knowing that we will have several new vulnerabilities that require remediation. I'll be attaching the spread sheet he sent which documents the vulnerabilities we anticipate. It is a list of 180 vulnerabilities, but his export doesn't account for the suppressions that VRO creates so the list actual list of resurfacing vulnerabilities won't be nearly that long.

[lisac]

other follow-ups from the 6/17 call:

• from Jacob: a list of the vulnerabilities with the debian issues filtered out: #team-abd-vro
• the suppressions applied 7/16 are set to expire 7/23 (visible in Aqua, filter by "vro-")

[lisac]

update: from the previous note, i had expected at least one set of suppressions to expire yesterday (and to need to address SecRel failures today). however, it happens that SecRel builds are passing today.

checking Aqua now, i see the suppressions have been extended, and there are two in-place for our repo:

• Short Term Suppression For Debian 13 (8 days, Jul 31) - appears to be smaller of the two (less in scope). example of what's in this one versus the other: CVE-2023-25585 (binutils)
• SRAC: Debian 13 Issues (90 days, Oct 22)

[nelsestu]

We are in the clear with regard to non-suppressed vulnerabilities. @lisac the Debian 13 suppression rules that you mention are legit and should remain in effect until Debian is able to mark that remediation production worthy. Until then, Debian 13 is marked beta, which is technically released, but not adoptable by our standards. The catch-all suppression rule that was in effect last week had expired as of yesterday, so SecRel runs since July 24 have only included the Debian 13 vulnerabilities mentioned above. So I am marking this issue complete, but @lisac feel free to correct or amend this issue if you feel like something else is still bound to bite us.