u/Hadsa_CounterStrike

DHIS2 is the system behind malaria, TB, and immunization reporting across most of the developing world's national health ministries. It turns out the application ships with a default admin password, derived from the platform's name, and never forces anyone to change it, not at setup, not ever.

This was flagged to the team behind it in March, followed up on twice, no real response in 90 days. The fix is a single line of code, force a password change on first login, it just doesn't exist yet. Full piece here if you want the detail: https://scrutora.com/blog/dhis2-default-credentials

(I'm affiliated with the company that did this analysis, sharing because the underlying issue matters regardless of who found it.)

Three months ago I joined a friend to start building a platform which can be useful to both engineers & Compliance professionals. Usually, both sound "greek" to each other.

So I started reading India's DPDPA (because that enforcement is on the radar) text next to actual code.

Section 8(5), "reasonable security safeguards," sounds like a sentence a lawyer wrote for other lawyers. But Rule 6 turns it into specific things you can actually check - Encryption at rest, Access logging, Breach detection monitoring.

That is a code review checklist wearing a legal costume.

Every SAST tool I looked at, Semgrep, Checkmarx, Bearer, finds the same underlying issue. Unencrypted field. Missing access control. PII sitting in a log line. But it gets reported as a CVE or a CWE ID. Nobody on an engineering team is translating "CWE 312: Cleartext Storage of Sensitive Information" into "this is your clause 8(5) exposure ahead of the May 2027 deadline" at 11pm before a release. There is probably an Information Security team across the vertical - which makes this too & fro a tedious business. Startups, unfortunately, have no such heft.

That translation gap, between what the scanner finds and what the regulator actually asks for, is the real problem. As far as I can tell nobody in India is building for it specifically.

So we built a scanner that does AST and CFG taint analysis and maps every finding directly to the clause text from DPDP.

And we built this not as a replacement for your compliance teams, auditors, DPO's or your grievance handling process. Those are operational SLAs, not code problems, and I am not going to pretend software solves them. We built this as force multiplier so that evidence collection doesn't have to be such a cumbersome process that it is right now.
And it does solve catching the technical clause 8(5)/Rule 6 gap continuously, before it becomes a finding your auditor or the Data Protection Board catches first.

We are trying to Shift Left "code compliance", similar to what happened with security nearly a decade ago.

Not trying to sell anything here. We are pre revenue and pilot ready, and looking for 5-7 teams who will actually run it against their codebase, tell us what is broken, and shape what we build next. In exchange you get free access and a direct line to me or the CEO, not a sales rep (We are only 2 people team and we intend to keep it this way till we have a rolling revenue).

Three months ago I joined a friend to start building a platform which can be useful to both engineers & Compliance professionals. Usually, both sound "greek" to each other.
So I started reading the actual DPDPA text next to actual code.

Section 8(5), "reasonable security safeguards," sounds like a sentence a lawyer wrote for other lawyers. But Rule 6 turns it into specific things you can actually check - Encryption at rest, Access logging, Breach detection monitoring.

That is a code review checklist wearing a legal costume.

Every SAST tool I looked at, Semgrep, Checkmarx, Bearer, finds the same underlying issue. Unencrypted field. Missing access control. PII sitting in a log line. But it gets reported as a CVE or a CWE ID. Nobody on an engineering team is translating "CWE 312: Cleartext Storage of Sensitive Information" into "this is your clause 8(5) exposure ahead of the May 2027 deadline" at 11pm before a release. There is probably an Information Security team across the vertical - which makes this too & fro a tedious business. Startups, unfortunately, have no such heft.

That translation gap, between what the scanner finds and what the regulator actually asks for, is the real problem. As far as I can tell nobody in India is building for it specifically.

So we built a scanner that does AST and CFG taint analysis and maps every finding directly to the clause text from DPDP.

And we built this not as a replacement for a your compliance teams, auditors, DPO's or your grievance handling process. Those are operational SLAs, not code problems, and I am not going to pretend software solves them. We built this as force multiplier so that evidence collection doesn't have to be such a cumbersome process that it is right now.
And it does solve catching the technical clause 8(5)/Rule 6 gap continuously, before it becomes a finding your auditor or the Data Protection Board catches first.

We are trying to Shift Left "code compliance", similar to what happened with security nearly a decade ago.

Not trying to sell anything here. We are pre revenue and pilot ready, and looking for 5-7 early stage teams who will actually run it against their codebase, tell us what is broken, and shape what we build next. In exchange you get free access and a direct line to me or the CEO, not a sales rep (We are only 2 people team and we intend to keep it this way till we don't have a rolling revenue).