Ask Your Dev Team about their security practices

Security is one of those topics where people nod along and assume it’s being handled. Don’t assume. Ask.

The scope of “security” varies depending on your project, your industry, and your risk tolerance. But it generally breaks down into three areas.

Application security

This is the code itself. Is the software built to resist attacks?

• Authentication and authorization: How do users prove who they are, and how does the system decide what they’re allowed to do? Weak authentication is one of the most common vulnerabilities in software.
• Input validation: Does the application check and sanitize everything users submit? SQL injection and cross-site scripting are decades-old attacks that still work because developers skip this step.
• OWASP Top 10: The Open Web Application Security Project maintains a list of the ten most critical web application security risks. Ask your developer if they’re familiar with it and how they address it. If they haven’t heard of OWASP, that’s a red flag.

Ask your developer: “What specific practices do you follow to secure the application layer?” You’re looking for concrete answers, not “we take security seriously.”

Infrastructure security

This is the environment your software runs on: servers, networks, cloud accounts.

• Network security: Firewalls, encrypted connections, restricted ports. Your production environment should not be wide open to the internet.
• Access controls: Who can SSH into your server? Who has admin access to your cloud account? The answer should be as few people as possible, and every access should be auditable.
• Patching and updates: Operating systems and server software need regular security updates. Ask how quickly your developer applies critical patches.

A common gap: developers who build secure applications but deploy them to poorly configured infrastructure. Both layers matter.

Organizational security

This is the people side. It’s often overlooked.

• Who has access to what? Your developer should be able to tell you exactly who on their team can access your codebase, your servers, your databases, and your third-party services.
• What happens when someone leaves? Employee offboarding should include revoking all access immediately. Not next week. Immediately.
• How are credentials managed? Passwords, API keys, and secrets should be stored in a secrets manager, not in a shared spreadsheet or a Slack message.

Security audits and penetration testing

If your project involves sensitive data, financial transactions, or regulatory requirements, security audits and penetration testing should be part of the conversation.

Ask your developer:

• “Do you conduct security audits? How often?” Annual is common. More frequent is better for high-risk applications.
• “Have you done penetration testing?” This is where a third party tries to break into your system to find vulnerabilities before a real attacker does.
• “Would you support a client-initiated security audit?” If a developer resists an independent security review, ask why.

Not every project needs a full pen test. But every client should know where their developer stands on the topic.

Keep it separate from data privacy

Security and data privacy are related but distinct. Security is about protecting your systems from unauthorized access. Data privacy is about how you collect, store, and use personal information. We covered data privacy in issue 16. This issue is about the locks on the doors, not the policies about what’s inside.

---

Expect better. Build better.