We use one of the known compliance platforms for audits which also help set some level of automation. I know that this doesn’t cover everything and each company may have opportunities for more custom automations. But I’d love to know from experiences/projects on what can you realistically do? ( PS - I am NOT looking to buy another tool/vendor)

My issues are:
1. The automation should really be useful. If I spend a week building it and need 2-3 hrs a month for maintenance just so that it can provide what a simple screenshot covers, it probably doesn’t make sense.

1. Generally companies already have tools for cloud monitoring, EDR, etc. If a tool already flags an over privileged pod, or a misconfigured S3 bucket; it doesn’t make sense to set monitoring for that again?

2. I have been following the GRC engineering hype and I do believe that there is potential and I just don’t know enough. But there are some things which seem inefficient, not worth it, home project like, or sometimes just over engineered.

I’d love to exchange ideas on what someone actually implements through an organization and if they’ve truly found it to be worth it!

When we scope a smart contract audit, the boundary usually lands around the code the client controls. That sounds unremarkable until you look at what these systems delegate. A contract that checks permissions through an external registry, resolves its own logic through a beacon, and deploys proxies from templates approved elsewhere is calling out to three things the client may not own and we may not be engaged to review. We can see all of it, because the calls sit in the code in front of us. Reviewing it is a different engagement with a different budget.

We delivered four separate audits for one system, and all four came back with zero critical and zero high findings. That result is real. The contracts were well written and the project team fixed what our auditors raised. Every one of the four reports also named, in its Potential Risks section, two components that no audit had reviewed: the authorization layer that decides whether a caller may write to state, and the upgrade authority that decides which implementation each proxy runs.

A severity summary counts findings inside a boundary. It carries nothing about what sat outside that boundary, and it cannot, because nobody looked there. Those four zeros describe four passes over the same contracts, and a fifth audit of the same scope would produce a fifth.

We helped draw that boundary and were paid for the work inside it. I would make most of the same calls again, because the authorization layer belonged to another team and refusing to review anything until everything is in scope produces no review at all. What I notice is where the two facts end up in the document. The count goes into a table at the front, and the dependency goes into prose near the back, which is roughly where readers stop treating it as part of the finding.

What we see from the delivery side is which part of the report gets quoted back to us, and it is almost always the table. The scope section is the part that says what the table is a statement about, and it is the part that stays in the PDF. So the sign-off that the audit coverage was adequate for the filing usually happens on the count, by someone who has not looked at the boundary the count was taken inside.

Who signed off that your audit scope was sufficient, and were they reading the table or the boundary?