We already had a security scanner

K.Chandini Subudhi — Wed, 30 Sep 2026 13:14:09 +0000

The bigger question was:

What happens if it remembers?

While building SecurePush for HackWith Hyderabad 3.0, we started with a pretty straightforward idea.

A developer runs git push.

Before the code reaches the remote repository, SecurePush checks the changes for security problems.

If something is wrong, it explains the issue and suggests a fix.

The developer decides whether to accept it.

The fix gets applied, the code is verified, and the push is either allowed or blocked.

That part was fairly straightforward.

Then came Hindsight.

Adding memory changed the workflow

We didn't want Hindsight to just be something we connected to the project because the hackathon required it.

We wanted there to be an actual reason for SecurePush to remember things.

Think about what happens during a normal security review.

A vulnerability is found.

A fix is suggested.

The developer accepts or rejects it.

Maybe the fix works.

Maybe it doesn't.

Maybe the same kind of issue appears again a few days later.

Usually, that history is gone from the perspective of the next review.

We wanted to change that.

So what does SecurePush actually remember?

Not the entire codebase.

Not every line of code.

And definitely not the actual passwords, API keys, or credentials it finds.

SecurePush remembers the useful parts of a security review.

Things like:

What security issue was found
Which file it was found in
The severity of the issue
What fix was suggested
Whether the developer accepted or rejected the fix
Whether the verification passed or failed
Whether the push was ultimately allowed or blocked

For example, imagine SecurePush finds a hardcoded credential in src/config.ts.

It suggests moving the credential into an environment variable.

The developer accepts the fix.

The change is applied.

Tests pass.

The push is allowed.

Hindsight can remember that interaction.

Something along the lines of:

A hardcoded credential was found in src/config.ts. The developer accepted the environment-variable remediation. Verification passed and the push was allowed.

The actual credential is not what we want to remember.

We want to remember the security event and its outcome.

Then comes the next review

This is where the memory becomes useful.

A developer makes another change later.

Before reviewing the new code, SecurePush can ask Hindsight:

"Have we seen anything relevant to this change before?"

Hindsight searches the repository's previous security memory and returns relevant context.

Maybe it finds that the same file had a hardcoded credential before.

Maybe it finds that the developer previously accepted a particular remediation.

That information is then passed into the security review.

So the new review isn't completely isolated from what happened before.

But memory doesn't replace the security check

This was an important part of the implementation.

Just because Hindsight remembers that something happened before doesn't mean SecurePush assumes the same issue exists now.

The current code is still checked.

The recalled information is treated as historical context.

So if Hindsight says:

A hardcoded credential was previously found in src/config.ts.

SecurePush still needs to look at the current diff and determine whether there is actually a credential problem now.

The memory helps the agent understand the history.

It doesn't make the decision for it.

The complete flow

The final workflow looks like this:

Developer changes code

↓

git push

↓

SecurePush checks the changed code

↓

Hindsight recalls relevant security history

↓

Security review happens with that context

↓

A problem is found

↓

Developer accepts or rejects the proposed fix

↓

SecurePush applies and verifies the change

↓

Push is allowed or blocked

↓

The review outcome is remembered

And the cycle starts again.

The next review now has access to the history of previous reviews.

Why we made the memory visible

We also didn't want Hindsight to be something that only existed somewhere in the backend.

So we added a Memory section to SecurePush.

The idea is simple.

If SecurePush says it remembers something, you should be able to see what it remembers.

The memory can show the security issue, the file involved, the decision made by the developer, the remediation, and the result of verification.

It makes the whole process easier to understand.

You can see the difference between:

What happened

and

What SecurePush remembered from it.

There was another problem

A security tool that finds secrets has to be careful about what it stores.

If SecurePush finds:

API_KEY = "actual-secret"

we obviously don't want the actual secret ending up in the memory system.

So sensitive values are sanitized before they are retained.

The memory should say:

A hardcoded credential was detected and the developer accepted moving it to an environment variable.

It should never need to contain the actual credential.

This was one of the things we had to think about while connecting the security workflow with persistent memory.

What we liked about the idea

The interesting part of SecurePush isn't just that an AI can find a security issue.

There are already tools that can scan code.

The interesting part is what happens when the security tool doesn't forget every review.

A repository has history.

It has previous vulnerabilities.

It has fixes that worked.

It has decisions that developers made.

It has problems that may come back.

Normally, a lot of that context is spread across commits, issues, documentation, chats, and people's memory.

With Hindsight, SecurePush can keep some of that security context and use it during future reviews.

That doesn't mean the system automatically knows everything about the repository.

It just means every review doesn't have to start completely from zero.

Building SecurePush

For us, the project ended up being more than just connecting an AI model to a Git hook.

We had to think about the complete flow.

How do we detect the changed code?

How do we decide what needs to be reviewed?

How do we explain a security issue?

How do we let the developer stay in control of the fix?

How do we verify the change?

How do we remember the outcome?

And most importantly:

What information is actually worth remembering?

That last question became one of the most interesting parts of the project.

Because memory isn't useful just because you have a lot of it.

It is useful when the right information comes back at the right time.

What SecurePush became

We started with a simple idea:

Check code before it gets pushed.

Then we added another idea:

Remember what happened during the check.

Put those together and SecurePush became something a little different from a normal security scanner.

It doesn't just look at the current push.

It can also look back at the security history of the repository.

The current code still matters most.

But now the review has context.

That's what we wanted to explore with Hindsight.

Not just an AI that can find a problem.

An AI security agent that can remember the problems, decisions and outcomes that came before.

DEV Community: K.Chandini Subudhi