Fizzle and policies

Our 500th rule.

With our 333rd rule,

R333 – The FOR loop is empty (WMB)

We were able to come up with something fun around the 333rd rule.

Which is a nice beer.

Which is good for a little celebration.

In the case of our five hundredth rule, it's maybe like your 22nd birthday. Just another number.

Our new 500th rule does involve a file that we haven't look at before.

Our current rules relate to msgflow, subflow, esql and project files.

With our new rule, we will now consume the new replacement for BAR overrides, policy override files.

There is some more details on policies from the IBM site here.

From our point of view, if we are scanning your code to make sure that you are applying security appropriately which you develop code, such as Kafka security such as :

R338 – KafkaConsumer nodes should use SSL (WMB)

Then by applying a policy, they can just ignore that configuration at runtime and we have no way of checking that, in code at least.

If we are assuming that policies are part of the code base, which from the point of view of good DevSecOps, they should be. Then we can apply the same security checks to policies as we can to other code.

The implementation, from our point of view would different of course.

With the checks specific to flows and subflows, we look at the XML of those files, which follows a different schema to what the policy files follow. But the logic is similar.

This would be similar to what we would be looking to do with secrets detection.

Where we would to make sure that there are no hard coded passwords in our Java code, as well as no hard coded passwords in the property files that they your Java code might read.

For those that might be interested in secrets detection, there are some existing products that do this already:

https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning

https://www.gitguardian.com/monitor-internal-repositories-for-secrets

https://docs.gitlab.com/ee/user/application_security/secret_detection/

These can be, or are all very Git specific and handle specific secrets, mostly API keys and tokens. They may not handle DB passwords as well as say, an AWS users SSH key.

Secrets is also something that we also check as part of the SAST rules we implement (or SAST rules for other languages supported by a variety of products):

R18 – Credentials are in plain text (WMB)

Our rules won't check random files, so between SAST checks and secrets detection, you get pretty good coverage.

Circling back to policies, in the case here, with ACE and Kafka, we are looking to make sure that we aren't weakening our Kafka topic security, by turning off SSL in one of our applied policies. So the developer does the right thing by ensuring SSL is applied, and the that is turned off later by someone deploying the application. To check this scenario, we have added a new rule:

R500 - KafkaConsumer policy for nodes should use SSL (WMB)

More information on our products and on pricing can be found on our website:

https://bettercodingtools.com

You can also reach me via email at:

[email protected]

Or contact me via the contact page on our website:

www.bettercodingtools.com/contact

Regards

Richard