Cybersecurity for software companies is different from cybersecurity for a bank or a factory. Your main asset is code, your infrastructure lives in the cloud, your team works from laptops anywhere, and your customers trust you with their data. You probably do not have a security team, and you do not need one to get the basics right. You need the right priorities, in the right order.
This guide is for startups and small and medium software companies. It covers the seven priorities that prevent most real incidents, a 30/60/90 day plan, what to automate and what to outsource, and the compliance basics you will hear about from customers.
Why software companies are a specific case
Attackers target software companies for two reasons: the data you hold and the access you have to your customers. A compromised SaaS vendor can be a path into hundreds of customer environments. That is why enterprise buyers send security questionnaires, and why a single leaked key in a public repository can turn into a customer-facing incident.
At the same time, your attack surface is mostly visible to you: your repositories, your cloud accounts, your identity provider and your CI pipeline. That is good news. Most of the risk can be reduced with configuration and automation rather than expensive hardware.
The 7 cybersecurity priorities for a software company
1. Code security
Your product is your biggest attack surface. Injection, broken access control and insecure deserialization are still the most common ways applications get breached, and they are all visible in the code. See the OWASP Top 10 2025 for the categories and remote code execution for the worst case. The practical control is static analysis on every pull request, ideally AI SAST that reasons about authorization, plus human review for sensitive changes.
2. Secrets
API keys, database passwords and cloud credentials end up in git more often than anyone admits. Deleting a file does not remove the secret from history. Scan the full history with a secret scanner, rotate anything you find, move secrets to a manager or your platform's encrypted environment variables, and block new commits containing secrets.
3. Dependencies and supply chain
Most of your application is open-source code you did not write. Commit lockfiles, run software composition analysis continuously (new CVEs appear without new commits), and pin third-party GitHub Actions and base images. Our SAST vs SCA guide explains why you need both, and an SBOM lets you answer customer questions quickly.
4. Access control
- Single sign-on for every tool that supports it, so offboarding is one click.
- Least privilege: production database and cloud admin access only for the few people who need it.
- Offboarding checklist executed the same day someone leaves.
- Quarterly access review of GitHub organization members, cloud IAM and admin panels.
- Branch protection on main: required reviews, no force pushes.
5. Backups
Backups only count if you can restore them. Keep automated backups of databases and critical storage, keep at least one copy in a separate account or provider that production credentials cannot delete, and run a restore test on a schedule. A ransomware attack or a bad migration is a very different day when you know your restore takes 40 minutes.
6. Multi-factor authentication
Turn on MFA for email, identity provider, GitHub, cloud consoles, domain registrar, payment provider and password manager. Prefer phishing-resistant methods (passkeys or FIDO2 security keys) for admins. Enforce it at the organization level instead of relying on each person to opt in.
7. Incident response
You do not need a 40-page plan. You need one page that answers: who decides, who communicates with customers, how to revoke credentials fast, where logs are, which lawyer to call and what your notification obligations are. Run a 60-minute tabletop exercise once a year with a realistic scenario, like a leaked AWS key or a compromised employee laptop.
A 30/60/90 day plan
Days 1 to 30: close the obvious doors
- Enforce MFA on every critical account.
- Inventory: repositories, cloud accounts, SaaS tools, who has admin access.
- Remove former employees and unused accounts everywhere.
- Scan your main repositories for vulnerabilities, vulnerable dependencies and secrets in git history. Fix critical findings and rotate exposed keys.
- Verify backups exist and do one restore test.
Days 31 to 60: make it continuous
- Add security checks to pull requests: SAST, SCA, secrets and infrastructure-as-code.
- Set up branch protection and required reviews.
- Move to SSO where possible and document the offboarding checklist.
- Centralize logs for authentication, cloud admin actions and production access.
- Write the one-page incident response plan.
Days 61 to 90: prove it
- Run a tabletop exercise.
- Write short policies that match what you actually do: access, secrets, backups, vulnerability management.
- Prepare standard answers for security questionnaires.
- Decide whether you need an external pentest now; read vulnerability assessment vs penetration testing to choose.
- Decide whether ISO 27001 or SOC 2 is on your roadmap, based on what customers ask for.
What to automate vs what to outsource
| Area | Automate | Outsource or get help |
|---|---|---|
| Code and dependencies | SAST, SCA, secret scanning and IaC checks on every change | Periodic manual review of critical flows |
| Testing | Continuous code-level assessment | Penetration tests, annually or before big launches |
| Identity | SSO, MFA enforcement, provisioning | Initial setup if nobody on the team has done it |
| Backups | Scheduled backups and alerts on failure | Rarely needed |
| Incident response | Alerting on suspicious activity | An incident response retainer with a specialized firm |
| Compliance | Evidence collection | Legal advice, certification audits |
For code, this is where Nurbak helps. You connect GitHub and scan a repository; its own self-hosted AI model analyzes the code (the analysis does not send your code to OpenAI or Anthropic) and reports exploitable vulnerabilities with the file and line, dependency CVEs via OSV with fixed versions, GitHub Actions, Docker, Terraform and Kubernetes misconfigurations and secrets in git history, with a 0 to 100 score and plain-language explanations for people who are not security specialists. The free scan shows the three most important findings in full, and plans start at USD 79/month. It covers the code side; it does not replace a pentest, network security or your incident response. Start with a code security audit.
If you are comparing providers of pentesting and security services, our guide to penetration testing tools explains what automation covers and what still needs people.
Answering customer security questionnaires
Sooner or later a larger customer sends a spreadsheet with dozens or hundreds of security questions. Treat it as a checklist, not a burden. Most questions map to the priorities above: do you enforce MFA, how do you manage access, how do you handle vulnerabilities in code and dependencies, how often do you back up and test restores, do you have an incident response plan, do you run penetration tests. Keep a single document with honest, reusable answers and the evidence behind them (screenshots of settings, scan reports, the incident plan). Never answer "yes" to something you do not do: a questionnaire often becomes part of the contract, and a false answer is a bigger risk than a "not yet, planned for next quarter".
What does it cost?
There is no honest single number. Costs depend on team size, number of repositories and cloud accounts, whether you need certifications and how much you outsource. The practical approach: most of the first 60 days costs team time more than money, because MFA, SSO, branch protection, backups and access reviews are configuration. The larger line items come later: security tooling, external pentests and, if you pursue them, certification audits. Ask vendors for quotes scoped to your actual assets.
Compliance basics
- GDPR (EU): applies if you process personal data of people in the EU, wherever you are based. Requires appropriate security measures and, for certain breaches, notifying the supervisory authority within 72 hours. The most serious infringements can be fined up to 20 million euros or 4% of worldwide annual turnover, whichever is higher.
- LGPD (Brazil): applies to personal data of people in Brazil. Fines can reach 2% of the company's revenue in Brazil, capped at 50 million reais per infraction, enforced by the ANPD.
- Other local laws: many countries have their own data protection laws with their own requirements. Get local legal advice for the markets you sell to.
- ISO/IEC 27001: an international standard for an information security management system (ISMS). You certify through an accredited body. The 2022 version has 93 controls in Annex A.
- SOC 2: an attestation report under the AICPA Trust Services Criteria, common with US customers. A Type I report looks at control design at a point in time; a Type II report tests how controls operated over a period.
The good news: the seven priorities above map directly to controls in all of these frameworks. Doing the basics well is most of the preparation.
Common mistakes
- Buying tools before fixing basics. A SIEM does not help if admins have no MFA.
- Security as a yearly event. One pentest a year does not cover code that ships daily. Build it into the DevSecOps workflow.
- Policies nobody follows. Write what you do, then do what you wrote.
- No owner. Someone on the team needs security as an explicit responsibility, even part-time.
Bottom line
Good cybersecurity for a software company is mostly discipline: MFA, least privilege, clean secrets, patched dependencies, secure code, tested backups and a plan for bad days. None of it requires a large team. Follow the 30/60/90 plan, automate what must run continuously, outsource what needs independence, and start where most of your risk lives: a security audit of your code.