Security

Most people who build apps with Coodoo aren't security experts. That's why Coodoo thinks like an experienced developer: for every goal, every task, and now and then for the whole project. You don't have to do anything for it.

While planning: what needs extra care?

While planning, the developer writes down what the app does that needs extra care:

Part	Examples of what Coodoo watches for
Website or web app	No malicious code through input (XSS), security headers, protection against forged requests
Login and accounts	Storing passwords safely, sessions that expire, seeing only your own data, a limit on login attempts
Payments	Always calculating prices on the server, using the provider's payment page, only approving payments through a verified message from the provider
Database	No building queries from input (SQL injection), keeping each user's data separate
Personal data	Only keeping what's needed (GDPR), users can see and delete their data, nothing in logs
File uploads	Checking type and size, never running uploads
Public API	Securing every endpoint, limits on requests
AI features	Distrusting user input (prompt injection), keys only on the server, capping costs per user
Mobile app	No secrets in the app, tokens in the phone's secure storage

It also writes down the risks and how the goal prevents them, and the safe choices it made where you didn't give a choice. For each part, the developer and the reviewer get a checklist.

Always, for every project

• No passwords or keys in the code; they come from environment variables (an .env file).
• .env files never go into git. Coodoo adds to .gitignore at the start of each goal when needed, and does allow an example file .env.example with empty values.
• Well-known, maintained libraries for security; never writing encryption yourself.
• Checking all input from outside.
• Showing users friendly error messages, not technical details.

Coodoo's own scanners

Besides the reviewer's judgment, Coodoo runs its own checks that don't depend on an AI:

Scanner	Looks for
Keys in the code	API keys from AWS, Stripe, GitHub, OpenAI, Anthropic, Google, Slack and others, private keys, and passwords written directly in the code. Also an .env file that is in git
Vulnerable packages	Known vulnerabilities in the packages your project uses (npm audit and pip-audit)
Known bad patterns	Code that can lead to a vulnerability, using the Semgrep rules: unsafe HTML, dangerous functions, weak encryption and more. Semgrep is downloaded automatically
The running app	Whether your app gives .env or .git away to anyone who asks, and which security headers it sends

The scanners look at what the goal changed. When the whole project is checked, they look at everything.

The running app

During Starting and checking the app, Coodoo asks your app for /.env, /.env.local, /.env.production and /.git/config. If the app returns a real file, that's a critical problem: anyone could read your passwords. Missing security headers are passed on to the reviewer as a point of attention; that's normal during development, but the real site does need to send them.

Severity and what happens next

Severity	Meaning	Result
Critical	Can be abused right away, like a leaked key	Must be fixed; blocks merging
High	Serious vulnerability	Must be fixed; the review doesn't approve
Medium	Should be better	Advice for the developer
Low	Minor issue	For your information

A critical or high problem is never approved, not even if the reviewer wants to. The developer fixes it and the review happens again.

If a critical problem is still open when merging, Coodoo warns you. You can only continue if you deliberately check: I understand the risk and want to merge anyway.

Checking the whole project

An experienced developer doesn't only look at the newest work, but now and then at everything. For that, Coodoo regularly puts a Security check of the whole project goal at the front of the queue. The team then goes through all the code with the checklist, the scanners look at the whole project, critical and high problems get fixed, and smaller points get written down.

• You set how often under Autopilot settings → Check the whole project: Every day, Every week (the default), Every month or Only when I ask.
• A check only happens if something changed since the last one.
• To start one yourself: on the dashboard, under Your app's security, click Check now.

The overview: Your app's security

The dashboard has a Your app's security card with:

• the open problems by severity, each with the goal it was found in (hover over it for the technical explanation);
• what your app does that needs extra care (login, payments…);
• when the whole project was last checked, and how often that happens.

After a check of the whole project, problems from earlier goals no longer count: that check looked at everything.

Dependabot: vulnerabilities in packages

GitHub uses Dependabot to track whether the packages in your project have known vulnerabilities. Coodoo reads those alerts.

• The Security card on the dashboard shows the open alerts, with the version that fixes the vulnerability (Fixed in …) or No patch available yet.
• If critical or high alerts are open, a red Fix first bar appears at the top with a Fix now button.
• With Security first on (the default), Coodoo itself puts a goal to fix them at the front of the queue.
• Below the alerts is Fix … alerts. It takes on all open alerts at once, medium and low ones included. Coodoo puts one goal with priority in the queue, with the critical alerts first. The autopilot updates the packages and checks that build and tests pass.
• GitHub only closes an alert some time after the fix is on the default branch (usually main), sometimes only after a few hours. So Coodoo looks itself at which versions GitHub sees on that branch. If a package is no longer in the vulnerable range, it says Fixed, waiting for GitHub. Such an alert no longer counts and gets no new goal.
• If your project has a flow, a fix lands on the first branch first, for example development. Coodoo then shows Fixed on development, with Go to the Flow. Only after Promote to main does GitHub close the alert.
• If Dependabot is off for your repository, you'll see Turn on at GitHub.

See also

• Failsafes: what the agents may never do, whatever happens.
• Project vault: keeping keys safe.