In the imperative approach, the SaC solution helps you prepare automation scripts that apply your security one specific step at a time.

Imperative rules require a higher level of domain experience with your applications. Still, the reward is more control over how you accomplish vulnerability remediation, which is ideal when you need to make small changes, optimize for a specific purpose, or account for software quirks.

Log4shell is an excellent example where following the recommended patching of removing the JNDI Lookup class can break some applications. 

Rather than completely removing the class, it’s possible with imperative rules to specify specific conditions in your applications where you want the JNDI Lookup class to function but place constraints around what you expect from the outputs.

Below is an example imperative rule for CVE-2021-44228:

app("APACHE LOG4J - CVE-2021-44228 - v1.2, b2"):
    requires(version: ARMR/2.2)
    patch("CVE-2021-44228 :01"):
    function("org/apache/logging/log4j/core/net/JndiManager.lookup(Ljava/lang/String;)Ljava/lang/Object;",
        checksums: ["da55340ac1",
                    "02c6120d62",
                    "b04cf027e3",
                    "d3ad3c6d00",
                    "bb0462e72d"])
        entry()
        code(language: java):
            public void patch(JavaFrame frame) {
                String payload = frame.loadStringVariable(1);
                log("Forcing JndiManager.lookup() to return 'null' due to CVE-2021-44228", payload);
                frame.returnObject(null);
            }
            private static void log(String msg, String payload) {
                ArmrEvent event = ArmrEvent.load("ALERT", "HIGH");
                event.addExtension("msg", msg);
                event.addExtension("payload", payload);
                event.commit();
            }
        endcode
    endpatch
endapp