What is a secure software development process?
A secure software development process is a way of building software in which security is considered at every stage, from the first conversation about what must be protected to the updates that follow launch. It is not a product you can buy at the end or a test you run once. It is a set of habits that a team either has or does not have.
That matters to you as a buyer because security problems are very hard to see from the outside. A site with a security hole looks exactly like a site without one, until the day it does not. You cannot judge a developer's secure software development process by looking at the finished screens. You judge it by how the team answers a few specific questions, and whether the answers are specific or vague.
This guide gives you those questions. It is written for business owners, founders and operations managers who are hiring a developer or agency and do not read code. We build custom software and websites ourselves, so we will mention what we do, and we will also say where we stop. Security claims you cannot check are a warning sign in any proposal, including ours.
A caution before we begin. Nothing here is legal or compliance advice. If you handle sensitive data, such as health records or payments, talk to a qualified adviser about the rules that apply to you.
What does the NIST Secure Software Development Framework ask a supplier to do?
You do not need to know the framework to ask good questions, but it helps to know that a widely used reference exists. The US National Institute of Standards and Technology publishes the Secure Software Development Framework, known as SSDF, in its special publication 800-218. It describes secure development practices in four groups.
- Prepare the organisation. The team has defined roles, training, and rules for how security is handled in projects.
- Protect the software. Source code and build systems are protected from tampering, and releases can be verified.
- Produce well-secured software. Security is designed in, code is reviewed, and the software is tested for weaknesses.
- Respond to vulnerabilities. The team finds, reports and fixes problems after release, and learns from them.
The framework was written for organisations that supply software to government, but its structure is a useful checklist for any buyer. A small agency will not have the paperwork of a large vendor, and you should not expect it. What you can expect is a plain explanation of how each of the four groups is handled in practice: who reviews code, how access to the source is controlled, what is tested before release and what happens when a problem is found afterwards.
If a vendor cannot describe any of this in ordinary words, the process probably does not exist.
Which OWASP checks should a business application pass?
The Open Worldwide Application Security Project, known as OWASP, publishes free material that most web developers recognise. Two pieces matter here.
The OWASP Top Ten is an awareness list of the most critical security risks for web applications. It includes broken access control, where a user can see or change something they should not, injection, where an attacker's input is treated as an instruction, and insecure design, where the weakness is in the plan rather than the code.
The Application Security Verification Standard, or ASVS, is a more detailed list of requirements for testing web applications. It defines three levels of verification, from a baseline for all applications to a stricter level for applications that handle highly sensitive data.
You do not need to ask for a formal ASVS audit on a small business site. You can ask something simpler: "Which of these risks do you design and test against, and how?" A confident team will talk about login and permissions, input validation, protecting data in transit and at rest, and how errors are handled. A weak answer is "we use a secure framework", which is true of almost everyone and tells you nothing.
The access-control question
Broken access control is worth a special mention, because it is the mistake most likely to hurt a business application. Picture a customer portal where the address of an invoice contains a number. If changing the number shows another customer's invoice, access control is broken, even though login works perfectly. Ask the developer how the software decides who may see each record, and whether that rule is enforced on the server rather than only hidden in the interface.
Who owns the accounts and secrets?
This is the most practical security question a buyer can ask, and it needs no technical knowledge.
Every software project runs on accounts: hosting, the domain name, the database, the email service, payment providers, analytics and code storage. Each has logins and keys. If those accounts are registered to your developer, you depend on them for access, you cannot see who else has a login and you may lose the software if the relationship ends badly.
The safer arrangement is simple.
- Accounts are registered in your name, with your email, and the developer is added as a user.
- You can see the list of people who have access, and remove any of them.
- Keys and passwords are kept in a secrets store or the host's settings, not in the code or in chat messages.
- Admin logins use two-step verification.
- When the project ends, access is removed for people who no longer need it.
This is also the arrangement that makes handover clean. It is how we run our projects: the repository, hosting, domain and third-party accounts are registered to the client from the start. Our guide on who owns your website after a developer builds it covers the ownership side in more detail.
How are dependencies kept up to date?
Modern software is assembled from hundreds of third-party libraries. Most of the code in a typical web application was written by somebody else. That is normal and efficient, and it means that a security fix in one of those libraries becomes your problem the day it is published.
The weak point is not the first release, when everything is current. It is month eight, when nobody has updated anything and a known vulnerability sits in a library the whole internet knows about. This is why websites and applications tend to break or become exposed over time, as we explain in why websites break over time.
Ask these questions.
- Who checks for security updates, and how often?
- How quickly are critical fixes applied?
- Are updates tested before they go live, or applied blindly?
- Are you told what changed?
- Is this included in a support plan, and for how long?
Automated tools can list known vulnerabilities in a project's libraries, and a good team runs them regularly. A support plan that includes updates turns this from a worry into a routine. If you want to see what that covers, look at what a website maintenance and support service includes.
What about the code itself?
Even without reading code, you can ask how it is made safe.
- Code review. Is every change looked at by a second person before it goes live? On a very small team this may be a rule rather than a department, but it should exist.
- Strict typing and validation. Does the team use languages and settings that catch whole classes of errors while the code is written? We write our projects in TypeScript with strict settings for this reason.
- Separate environments. Is there a test version of the software that is not the live one, so that changes can be checked before customers see them?
- Backups. Where are they, how often are they taken and has anyone tested restoring one?
- Logging. If something goes wrong, can the team see what happened and when?
Record-keeping deserves a mention for business systems in particular. On software where somebody will eventually ask "who changed this, and when?", an audit log is not optional. We build audit logging and role-based permissions into internal systems and customer portals where the records matter, and we explain in advance which actions are recorded.
What does India's data protection law add?
If your software collects personal data from people in India, the Digital Personal Data Protection Act, 2023 applies to how that data is handled. The Government of India notified the implementing rules in November 2025, with obligations phased in over time, as described in the Press Information Bureau release.
In plain terms, the business that decides why and how personal data is used stays responsible for it, even when a developer or vendor processes it on its behalf. The law expects reasonable security safeguards and notice to affected people and the regulator if a breach occurs. Our summary of what the DPDP Act means for a business website covers the practical points, such as consent forms and who is responsible.
What this changes for your developer conversation: ask how personal data is stored, who can see it, how long it is kept and how a breach would be detected and reported. Security of the build and legal responsibility for the data are linked, and a vendor who cannot answer questions about the first will not be much help with the second.
The Indian Computer Emergency Response Team, CERT-In, also issues directions on reporting cyber incidents that apply to many organisations. Whether they apply to you, and what they require, is a question for your adviser, not something to take from a blog post.
Questions to ask before you sign
Here is the list to take into a meeting. None needs technical knowledge to ask, and the quality of the answers tells you a good deal.
- Who will have access to my source code and accounts, and how is that controlled?
- Will accounts be registered in my name?
- How do you decide who can see or change each record, and where is that enforced?
- How is sensitive data stored and protected, in transit and at rest?
- How do you find and fix security updates in the libraries you use?
- Is every change reviewed by a second person before release?
- What do you test before launch, and can I see a summary of the results?
- Where are backups kept, and have you tested a restore?
- What happens if something goes wrong: how do I find out and how quickly are you expected to respond?
- What does your support plan cover, for how long, and what is not included?
- Do you hold any certification, and can you show it?
- What will you tell me you cannot guarantee?
The last question is the most revealing. Nobody can guarantee software is perfectly secure. A team that says so, and then explains what they do to reduce the risk, is more trustworthy than one that promises it cannot be hacked.
For the wider decision of whom to hire, our guide to choosing a custom software development company covers the other criteria, and the custom software service page explains how we approach projects.
Red flags that should make you pause
- "We use a secure framework, so it is secure." Frameworks help. They do not make an application safe.
- The vendor holds all the accounts and will transfer them "at the end".
- Passwords or keys shared over chat or email.
- No separate test environment. Changes go straight to the live site.
- No plan for updates. The software is delivered and then left alone.
- Vague answers to specific questions, or irritation at being asked.
- Security claims that cannot be shown, such as a certification with no document behind it.
- Promises of a fixed result, such as "unhackable".
One red flag may be explainable. Three together are enough to look elsewhere.
The short version
A secure software development process is visible in how a team answers practical questions, not in how confident its sales page sounds. Look for four things: accounts and keys that belong to you, access that is controlled and recorded, updates that are planned and paid for, and answers that are specific about what is and is not covered.
You do not need to become a security expert. You need to ask the dozen questions above, notice when an answer is vague and put the important points in writing. If you do that, you will already be ahead of most buyers.
