A lot of it was written by AI
Cursor, Copilot or Claude Code wrote big parts of the app. It passes the demo. Nobody has checked what happens when a user asks for data that isn't theirs.
Explore
Consultancy · Code & security audit
Know what's in your code before an attacker does
A lot of code now gets written by AI and shipped without anyone reading it closely. It works in the demo. It also skips permission checks, pulls in packages that are outdated or don't exist, and leaves API keys in the repo. Older code has a different problem: a PHP version past end of life, a framework nobody dared to upgrade, libraries that stopped getting security patches years ago. We read the code, run static, dependency and secret scans, and give you findings ranked by risk, each with a fix your team can act on.
- 130+People, remote across Poland
- 12 questionsIn our public AI readiness scorecard
- 5.0Clutch rating, 11 reviews
This is for you if you're not sure what's in your code anymore
Nobody on the team fully understands parts of it
The code changed hands, or it was generated faster than anyone could read it. Now people avoid touching certain files, and no one can say why they work.
Updates kept getting skipped
PHP is past end of life, the framework is several major versions behind and the libraries no longer get patches. The jump to current versions now looks like a project of its own.
The scanner report needs priorities
You have hundreds of warnings. Your team needs to know which ones an attacker can actually reach and which can wait for the next sprint.
What you get. Findings a delivery team can use
A review of the code that matters
Engineers read the areas you pick, like login, permissions, payments and data exports. We record the versions and boundaries we reviewed.
A check of AI-written code
We look for the usual problems: missing authorization checks, made-up or abandoned packages, secrets in code and git history, insecure snippets copied from file to file.
A ranked fix backlog
Each finding comes with evidence, impact, a recommended fix, an effort estimate and a way to check it's really fixed.
A map of your update debt
Runtime, framework and library versions checked against their support dates. You see what no longer gets security patches and an upgrade path you can take one step at a time.
What we check first
Authentication and authorization
Who can read and write what, enforced in the database and the API, not only in the screens. Row-level security that holds outside the happy path.
Secrets and keys
What shipped to the browser or the repo history, what each key can do, and a rotation plan that does not take the app down.
Public surface
Data APIs exposed by default, admin routes, file storage, test environments with real data, headers and CORS.
Tenant isolation and roles
One company cannot see another's records; team roles, admin tools and white-label setups built on that boundary.
Dependencies and the pipeline
Known vulnerabilities, secret scanning, who can merge and deploy, and whether a change can reach production unread.
Error handling and logging
Would anyone notice when something breaks or someone probes the app, and what would they see.
Tech stack. Scanners first, then people
Scanners catch the known classes of issues. Engineers catch the ones specific to your product, like who is allowed to see what.
Tech stack
- OWASP ASVS
- OWASP Top 10
- Semgrep
- SonarQube
- Snyk
- Dependabot
- Trivy
- gitleaks
- OWASP Dependency-Check
- OWASP ZAP
- Burp Suite
- GitHub Advanced Security
- PHP
- Laravel
- Symfony
- WordPress
- Node.js
- Java
- .NET
- Python
- Ruby on Rails
How we work
Follow the risk into the code
We agree on the scope before we ask for access. Read-only access is usually enough to start. The report says what we checked, what we found and what we did not look at.
Their ability to quickly deliver high-quality solutions while maintaining transparency in communication is rare.
How it works. From audit scope to a ranked fix list
Pick what to review
Repositories, sensitive flows like login, payments and data exports, and the decision the audit should help you make.
Run the scanners
Static analysis, dependency checks, secret scanning across code and git history, and every runtime and framework version against its end-of-life date.
Read the code
Engineers follow the risky paths by hand: who can call what, where the data goes, which AI-written parts nobody has checked. A scanner can't judge that.
Rank it and walk you through
Findings are ordered by real exposure, not scanner severity. We go through the report with your team so they can plan the fixes and the upgrades.
Proof, not promises
AI · FinTech
Taking over a crypto platform no one else could ship
Security · Government
Financial-crime investigation software for Poland's authorities
FinTech · Government
AML-grade oversight for U.S. political ad spend, built from scratch
Questions about a code review engagement
- No. We work in your repository, your cloud and the tools your team already uses. If one of them gets in the way of the work, we tell you what and why, and you decide.
- With a 30-minute scoping call. We look at what you have and what you need, then propose a first step with its scope and price before any work starts.
- Only if it is in the agreed scope. Any active testing beyond the agreed methods is defined separately before work begins.
- Code and infrastructure review can begin with appropriately scoped read access. If a finding needs additional verification, we discuss the required access and method with you.
- Findings include an estimate of the work needed where the available evidence supports one. Uncertainty and dependencies are recorded so your team can refine the plan.
- The report is written for the people who will maintain the application. They can use the findings and verification guidance without engaging us for implementation.
- An audit produces a bounded assessment and remediation guidance. Our security for vibe-coded apps service can continue into implementing and checking the agreed hardening changes.
- The problems AI code tends to have. Endpoints that check if you're logged in but not if the record is yours. Packages that are outdated, abandoned or don't exist at all. API keys and passwords in the code or in git history. One insecure snippet copied into ten places. And parts nobody on the team can explain. Code like this usually passes the demo. We read it the way an attacker would.
- Each PHP branch gets about two years of active support and then about two more years of security fixes only. After that, no patches come out, even for known vulnerabilities. Frameworks and libraries drop old PHP versions too, so at some point you can't upgrade them one step at a time anymore. The longer you wait, the more the upgrade becomes a project of its own. The audit shows where you stand and a sensible order of upgrades.
- Keep updates small and regular. Dependency bumps every week or two, framework upgrades on a schedule, security patches as advisories land. Dependabot opens the pull requests, but someone still has to review, test and merge them. If your team has no room for that, our product maintenance service runs it as a stream of its own.
Choose the code paths you need reviewed
Discuss your project with our AI Architects. No commitment, just clear answers and a roadmap.
Direct contact
Mike KacprowiczBook a callChief Growth Officer