Coding agents enable anyone to turn their ideas into reality. However, building with security in mind is imperative to keep your application secure. There’s a lot of reference information about application security out there, but it often is jargon-heavy and targets developers or security professionals, not vibe coders. There are also many security tools available, but it can be confusing to know what type of tool to use and when. This post breaks down essential security terms and tools so that you can build safely from the start.
If you aren’t sold on the importance of application security or think it only matters to large companies, consider the PHP2Shell vulnerabilities disclosed in October 2026. These two vulnerabilities affect PHP, a programming language used by more than 70% of websites. They could allow an attacker to take control of a website’s server. The vulnerabilities are so serious that some organizations temporarily took services offline while installing security updates.
What is code security?
In simple terms, code security is the practice of writing secure code. Because application security starts with code security, taking a proactive approach early prevents major vulnerabilities later.
There are two main things we need to be concerned with when thinking about code security: the code you (or your agent) is writing (i.e., first-party code), and the code that is written by someone else but being used by your application (i.e., third-party code). With first party code, you are directly responsible for fixing the problem. Third-party code is treated differently because you are not the one who can fix the code, but you are responsible for using a version that does not have vulnerabilities. We often refer to third-party code as being part of the software supply chain, but more on that later.
What is first-party code?
First-party code is the code that you are producing and are thus responsible for. While being responsible for maintaining secure code might seem intimidating, you can most likely fix security issues by prompting the agent to fix them. There are automated security scans you can run to discover vulnerabilities, or you can simply ask the agent to do a security check. Checking for OWASP top ten vulnerabilities is always a good place to start.
What are secrets?
One of the simplest, yet most impactful ways to improve security is to avoid hardcoding secrets. This means that you should never write in the code any password, token, key, or any secret or credential that can be used to gain access to your resources. Instead, you can use environment variables that act as a placeholder that point to a specific hidden configuration file or a secret manager.
What is the software supply chain?
The software supply chain refers to everything that is used to develop and run an application, including dependencies, tools, and infrastructure. There are also open source code components used in the software supply chain, such as GitHub actions and Docker images, which can help you deploy and run your code. Of all these elements, third-party dependencies are usually the main focus in discussions about code security.
Now you might be thinking, why do I need to use third-party code? Technically you don’t, but it makes writing code much easier, whether it’s done by you or an agent. By relying on these open-source dependencies, you are using code that was already written by someone else and that is shared with the community to solve a problem. What’s important to understand in the context of AI-generated code is that coding agents use dependencies by default, often relying heavily on outdated versions.
Dependencies rely on other dependencies, so the risk starts to grow as you start to use them. There are two things in particular you need to be concerned about with third-party dependencies: vulnerabilities and malicious packages. Vulnerabilities in third-party dependencies are accidental code issues that usually require upgrading to the latest version once the issue is fixed. Malicious packages represent a more intentional threat and are becoming more common. With these packages, someone has purposefully added a malicious script in the version and released it for personal gain.
Overall, the concern with using third-party code is that dependencies can quickly accumulate vulnerabilities if the maintainer doesn’t have the time to address these security flaws.
Security questions to ask your coding agent
The cool thing about vibe coding is that you can ask the agent any questions you may have. The difficulty can be knowing exactly what to ask. Below is a list of good places to start, but it is not exhaustive.
Setup questions
These are the types of questions that should be asked before any code is written. The goal is to have some security requirements planned out so an agent has a path to follow.
- What sensitive data will this app handle (passwords, payment info, personal data, API keys), and how should each type be protected?
- What authentication and authorization approach fits this app, and what are the tradeoffs?
Follow-up questions
After the code is written, you should make sure the agent made the best decisions for security. Ask questions that make the agent explain why certain security decisions were made. This will force the agent to go back through the code, which might lead it to suggest a change.
- Can you do a security review on the application? Are there any concerns?
- Do any OWASP top 10 vulnerabilities exist in this code?
- What security tradeoffs did you make to keep this simple, and what would you fix before real users touch this?
- If you were a penetration tester, what's the first thing you'd try to break in this app?
- What third-party packages did you use? Are any of them outdated? Do any have known vulnerabilities?
- Does any of this code contain hardcoded API keys, passwords, or tokens? If so, where, and how do I move them to environment variables or to a secrets manager?
- Are default credentials or debug modes left enabled anywhere?
- Is there a
.envor config file here, and is it excluded from version control (.gitignore)? - Are there any insecure coding patterns or logic flaws present?
- Is there anything concerning about the current authentication and access controls configuration?
- Are cloud storage buckets, databases, or admin panels publicly accessible when they shouldn't be?
- If this is deployed, what's exposed to the internet that doesn't need to be?
What are the different types of code security tools?
Security tools come in all shapes and sizes. While many tools are paid, there are also open source tools that function similarly. The list below includes the most common types of tools.
Software Composition Analysis (SCA)
Tools of this type scan all the open-source dependencies that are being used in the application and alert you if there are any vulnerabilities. Most providers will also tell you what version you can upgrade to in order to eliminate that vulnerability.
Static Application Security Testing (SAST)
This type of tool is focused on looking at your first-party code for vulnerabilities. Most commonly, these tools scan the written code without running that code. They are good for early detection while you are actively coding but can provide more false positives than other tools do.
Interactive Application Security Testing (IAST)
Tools in this category look at how data is flowing into a running application to find code vulnerabilities. Since they require a running application, they are generally used later in the software delivery life cycle compared to SAST tools. However, they also tend to be more accurate.
Dynamic Application Security Testing (DAST)
Tools that perform this type of security scan run pre-configured automated tests against a running application. They are not interchangeable with SAST or IAST tools.
Infrastructure as Code (IaC) Scanning
Tools that use this type of scanning are focused on looking at any IaC files for risky settings and misconfigurations.
Secret Scanning
Secret scanners search your codebase for hardcoded credentials, API keys, and passwords.
How Datadog can help
Security scans are a great way to understand what is happening in your code. Datadog Code Security has many types of tools you can use to gain visibility into your application, including SCA, SAST, IAST, IaC, and Secret scanning tools.
Datadog also has two open source tools that can be used for supply chain security: GuardDog to flag malicious packages and Supply Chain Firewall to block malicious packages from being installed.
Conclusion
The good news is that you do not need to become a security expert before bringing an idea to life. Start with a few basics: keep secrets out of your code, scan both first-party and third-party code, update your dependencies, and ask your coding agent to check for common vulnerabilities.
The goal is not to build a perfectly secure application on your first try. It is to understand what your application uses, recognize the risks, and make security part of how you build from the start. Addressing issues along the way is much easier than responding after your application or its users have been put at risk.
