defsec schema

[itaysk]

After discussing with @simar7 (cc @nikpivkin ), I understand that:

1. rego check can refer to a schema for input validation
2. the schema is generated based on the check's code

This feels backwards to me, and defeats the goal of having input validation and type checking, since the schema will always satisfy the validator/type-checker even if there's a mistake.
The schema should be a reflection for the data model, and should be generated from it.

Also, the schema today is shipped with the defsec checks bundle. The bundle has a different lifecycle than Trivy, and that is also not good.
The schema should be a contract from the engine to the checks. This will create clear boundaries between checks and the engine and naturally solve some existing and potential issues (also mentioned here #4197).

Proposed solution:

1. Formalize the defsec common data model as a "source of truth" across all relevant services (doesn't have to be across the board).
2. Generate json schema from this defsec data model
3. Couple the json schema with Trivy's lifecycle, probably by embedding it into the binary
4. Checks need to either commit to a schema or omit it (and go schema-less)
5. When we want to support a new data model (e.g a new AWS service), we must update the data model first, regenerate schema, and only then can write a check with it (unless it's schema-less).

[knqyf263]

the schema is generated based on the check's code

Interesting.
https://github.com/aquasecurity/trivy-policies/blob/0a29e9e7b5958608ec9aae8e47ef4b7a9e3ef308/pkg/rego/schemas/builder.go#L12

Can we clarify again what we want to validate the input for?

1. Ensure that the data passed by the engine is what Rego wants.
2. To make it easier for users to write custom policies by specifying the data type of the input

Is there something else?

The current approach achieves No.2 as we have JSON schema, while No.1 is not achieved because the schema is now generated based on the engine, and the validation won't fail. Am I understanding correctly?

Itay suggested defining the data model separated from the engine, right?

[simar7]

Yes that makes sense. In this case, we can use these structs to generate the schema by first decoupling the schema from the policy bundle and then secondly generating and embedding into trivy (via trivy-iac import) like we discussed. Me and @nikpivkin will start to look into it.

[knqyf263]

If we are indeed building the schema based on the user provided rego (I didn't read through the code yet), can you clarify how you think we achieve 2?

As @nikpivkin already explained, it is not dynamically generated when a policy is passed. The schema is generated from Go structs, and defsec embeds the schema and keeps using it (IIUC).

[simar7]

We can build the schema from state.State{} a struct that we have for cloud state. Pairing this with schema generation and decoupling this from the generation of the policy bundle gets us to a point where we can embed the schema with release of Trivy (via trivy-iac repo).

I've started the work to do so here aquasecurity/trivy-iac#32

[knqyf263]

When policies for a new AWS service are added, will Trivy work with the embedded schema? I'm wondering if the embedded schema doesn't know about the service and scanning fails.

[simar7]

When policies for a new AWS service are added, will Trivy work with the embedded schema? I'm wondering if the embedded schema doesn't know about the service and scanning fails.

We handle this today already but in the future it'll be easier to do so as Trivy will not fail out but handle it gracefully. I've added some more info here #5138 (comment)