Your AI Coding Agent Can Write Code. Can It Secure It? Meet SecFoo
SecFoo is an open-source security tooling project designed to turn AI coding agents into structured security reviewers for your codebase.
Instead of treating security as something that happens only at the end of development, SecFoo brings AI-assisted security analysis closer to the development workflow.
What Is SecFoo?
SecFoo is a context-based security architectural assessment orchestrator.
The idea is simple:
Give an AI coding agent the right security review task, the right context, and a structured workflow — and let it analyze your project for security concerns.
SecFoo supports different security review skills, including areas such as:
Security architecture review
Threat modeling
SAST
Software composition analysis and reachability
Secret scanning
Prompt review
Deployment readiness
Responsible AI compliance
This makes SecFoo more than a simple "find a suspicious line" scanner.
The goal is to help AI agents perform structured security reviews of applications and their architecture.
Why Do We Need AI-Assisted Security Reviews?
Modern applications are becoming increasingly complex.
A vulnerability might not exist because of one obviously dangerous line of code.
Sometimes the problem is the relationship between multiple parts of an application.
For example:
query = f"SELECT * FROM users WHERE id = '{user_id}'"
The query itself is clearly concerning.
But a security review also needs to ask:
Where did user_id come from?
Was it generated internally?
Or did it come from an HTTP request?
If untrusted input reaches the query without proper protection, the application may be vulnerable to SQL injection.
This is why context matters.
The question isn't only:
"Does this line look dangerous?"
It is also:
"How does data move through the application, and what happens when that data reaches this operation?"
That's one of the areas where AI-assisted security analysis becomes interesting.
SecFoo in Action
I wanted to see how SecFoo would perform in a controlled experiment.
So instead of testing it against a completely clean application, I created a small Python application and deliberately introduced three security vulnerabilities.
The three vulnerabilities were:
1. Hardcoded Credential
AWS_SECRET_KEY = "FAKE_SECRET_FOR_TESTING"
The credential was intentionally fake and created only for testing.
The purpose was to see whether the security review could recognize that sensitive credentials should not be embedded directly in source code.
2. SQL Injection
query = f"SELECT * FROM users WHERE id = '{user_id}'"
Here, user-controlled input could reach a SQL query without appropriate protection.
3. Command Injection
os.system(f"ping -c 1 {host}")
The test was designed to see whether the review could recognize the danger of passing untrusted input into command execution.
Running SecFoo
I used SecFoo's SAST skill to review the deliberately vulnerable project.
The command I used was:
secfoo run --skill sast --agent api --target . --project-name vulnerability-challenge --app-id ""
After the review completed, I used the dashboard to inspect the findings:
secfoo serve
The experiment was intentionally controlled.
I already knew exactly where the three vulnerabilities were.
That gave me a simple way to evaluate the result.
The Result
All three intentionally planted vulnerabilities were identified in my test.
| Security Issue | Detected |
|---|---|
| Hardcoded credential | ✅ |
| SQL injection | ✅ |
| Command injection | ✅ |
The interesting part wasn't simply that three warnings appeared.
The value was in seeing the security concerns presented as findings that could be investigated further.
Hardcoded credential
SQL injection and Command injection
What Makes SecFoo Interesting?
One of the things I find interesting about SecFoo is that it isn't positioned simply as another keyword-based security checker.
It provides a structured way to use AI agents for different types of security analysis.
That opens up several possibilities.
For example, instead of asking an AI coding agent:
"Review my code."
You can give it a much more specific security objective:
"Perform a SAST review of this application."
Or:
"Analyze the application's architecture for security risks."
Or:
"Perform threat modeling for this system."
The review becomes more structured and security-focused.
From Code Review to Security Review
There is an important difference between these two questions:
Code review:
"Is this code correct?"
Security review:
"How could this code be abused, and what happens when an attacker controls the input?"
That difference matters.
A developer may look at:
os.system(...)
and think about whether the command works correctly.
A security review should also ask:
Who controls the data being passed into that command?
That shift in perspective is what makes security analysis valuable.
SecFoo is designed to help bring that security perspective into AI-assisted development workflows.
When Could SecFoo Be Useful?
SecFoo can be useful when you want to add structured security analysis to your development workflow.
For example:
Before committing code
Run a security review before pushing changes.
During application development
Use security-focused AI reviews while features are still being developed.
Before deployment
Use deployment-readiness or security reviews to identify potential concerns before releasing an application.
For architecture reviews
Use security-focused analysis to think about risks beyond individual functions or files.
For experimentation
Create a deliberately vulnerable application and see what the security review identifies.
That last one is actually how I tested it.
AI Doesn't Replace Security Engineers
This is important.
SecFoo should not be treated as a magic button that guarantees an application is secure.
AI-assisted security analysis can produce useful findings, but those findings still need human validation.
Security engineers and developers still need to:
Verify whether a finding is real
Understand the application context
Evaluate the severity
Review remediation suggestions
Test the proposed fix
Consider risks that automated analysis may miss
The goal isn't:
AI instead of security engineers.
The more useful idea is:
AI assisting developers and security engineers with structured security analysis.
Why Open Source Matters
SecFoo is open source and released under the MIT license.
That makes it possible for developers to explore the project, understand how it works, experiment with it, and contribute to its development.
If you're interested in AI-assisted security tooling, you can explore the project directly:
Getting Started
You can install SecFoo with:
pip install secfoo
From there, you can experiment with the available security review capabilities and see how AI-assisted analysis works with your own projects.
I would recommend starting with a small test application rather than immediately pointing any new security tool at a production codebase.
A deliberately vulnerable test project is a great way to understand what the tool finds and how its findings are presented.
My Takeaway
AI coding assistants are already helping developers write software faster.
The next question is how we can use AI to help developers build that software more securely.
My experiment with SecFoo was small and controlled, but it gave me an interesting perspective:
Security review doesn't have to be limited to checking individual lines of code.
With the right context and structured review process, AI agents can become another useful tool in the security workflow.
If you're working with AI-assisted development and want to experiment with AI-powered security reviews, SecFoo is worth exploring.
And I'm curious:
What would you want an AI security reviewer to check in your codebase?
Architecture? Authentication? Data flow? Secrets? APIs? Something else?
Let me know.
