In declarative approaches, you specify the desired final state of the security you want to apply without dictating how to get it.

This behavior is ideal for CWEs, which refer to software weaknesses rather than specific instances of vulnerabilities within products or systems.

Declarative programming minimizes the factors that could affect the behavior of a piece of code to ensure that only a function’s input should affect the output, not what’s happening elsewhere in the program.

This approach enables Security-as-Code’s immutability and makes it possible to prevent vulnerability regressions.

For example, if SQLi vulnerabilities are rampant in your applications, it’s possible through SaC platforms to declaratively tell your applications that you never want to see another SQLi again.

From the time you deploy your SQLi rule, there’s no code that developers can add to the codebase that will override your rule.

Due to the nature of these rules, they inherently remediate zero-days in some instances. This inherent protection is the case for CVE-2022-42889, in which the process forking rule is more than sufficient for payloads supplied as Javascript code, as seen below:

app("nashorn CVE-2022-42889"):
    requires(version: ARMR/2.2)
    process("Deny any process execution"):
        execute("*")
        protect(message: "", severity: 7)
    endprocess
endapp

Security-as-Code solutions also provide imperative rules for more involved vulnerabilities like Log4shell (CVE-2021-45105), where conditionality and context are needed.