Cybersecurity for Software Companies: Real Security, Not Checkbox Compliance

A SOC 2 report does not stop a breach. A pile of policy documents does not stop a breach. ISO 27001 certification does not stop a breach. They’re useful for sales, useful for procurement, sometimes useful for insurance. None of them are security.

The companies that get breached in 2026 have certifications. They also have exposed API endpoints with broken authorization, JWT secrets in environment files committed to public repos, S3 buckets with overly permissive policies, and outdated dependencies with known RCEs. The pentester who finds these things finds them in 4 hours. The compliance auditor doesn’t look for them at all.

Compliance is a paperwork outcome. Security is an engineering outcome. They’re related but they are not the same thing. Here’s how we do the engineering outcome.

The compliance theatre problem

Most software companies under 100 engineers don’t have a security program. They have:

• A SOC 2 report obtained through Vanta or Drata.
• A policy folder in Notion.
• A “[email protected]” inbox no one watches.
• Maybe Snyk on their main repo.
• A vague plan to “do a pentest before our next renewal.”

This is fine for selling to mid-market customers. It is not fine for keeping customer data safe. We’ve worked with companies that passed SOC 2 Type II audits and had critical vulnerabilities we found within the first week of a security engagement.

The compliance frameworks aren’t the problem. They’re sensible at the design level. The problem is that companies treat the certification as the goal, not the engineering work behind it. They optimize for “passing the audit,” which has almost no overlap with “being hard to breach.”

What real security looks like is a continuous practice: code is reviewed for security before merge, infrastructure is hardened by default, secrets are rotated automatically, third-party dependencies are scanned and patched, and someone is actually trying to break the system from the outside on a recurring basis.

Pentesting: the reality

Let’s clarify what penetration testing actually is, because most companies who say they’ve had a pentest haven’t really had one.

A pentest is a manual effort by a skilled human to break into your system using the same techniques an attacker would use. It is not running Burp Suite Scanner overnight and emailing you the CSV. It is not Nessus exporting a report of CVEs in your dependencies. Those are vulnerability scans. They’re useful as inputs, but they are not pentests.

A real pentester does the following:

• Maps your attack surface (public APIs, exposed services, third-party integrations, user roles).
• Tests authentication and session management (token replay, JWT manipulation, password reset flows).
• Tests authorization (IDOR, privilege escalation, tenant isolation in multi-tenant systems).
• Tests business logic (race conditions in payments, abuse of refund flows, exploitable workflows).
• Tests for injection (SQL, NoSQL, command, template, SSRF).
• Reviews secrets handling and information leakage (error messages, debug endpoints, source maps in production).
• Writes proof-of-concept exploits for each finding. Not theoretical “this could be exploited” — actual working PoCs.

The deliverable is not a CVE list. It’s a report with severity-ranked findings, each with: reproduction steps, evidence (screenshots, request/response captures, scripts), business impact, and remediation guidance. Findings without working PoCs are noise.

We run two types of pentests:

• Black-box (we get a URL and a test account, nothing else). Simulates external attacker. Best for understanding what a real adversary sees.
• Grey-box (we get architecture diagrams, source code access, internal documentation). Simulates a sophisticated attacker with some insider information. Catches more, faster.

For most clients, grey-box pentest is better value. The point of pentesting is to find and fix vulnerabilities, not to prove you can hide them.

Pricing: from $8K for a focused 1-week engagement on a specific application, up to $25K for a multi-week assessment across application + cloud infrastructure + internal network.

Cloud hardening: the boring stuff that matters

The majority of breaches don’t come from clever zero-days. They come from S3 buckets nobody locked down, IAM users with admin access who left the company two years ago, and database snapshots that were “temporarily” made public.

Our standard AWS hardening pass covers:

IAM and identity:

• Root account locked behind hardware MFA, never used.
• All human users via SSO (Okta, Google Workspace, AWS IAM Identity Center).
• Service-to-service auth via IAM roles, never long-lived access keys.
• Least-privilege policies. We run IAM Access Analyzer and remove anything not actively used in 90 days.
• No * actions in policies unless there’s an explicit reason documented.

Secrets management:

• AWS Secrets Manager or Parameter Store (encrypted). Never .env files in S3. Never secrets in environment variables in plaintext.
• Automatic rotation for database credentials and API tokens.
• Sensitive secrets (signing keys, encryption masters) in AWS KMS with explicit policies.

Network segmentation:

• Private subnets for databases and internal services. No RDS or Elasticache instances with public endpoints.
• Security groups locked down to specific source ranges, not 0.0.0.0/0.
• VPC endpoints for S3, DynamoDB, ECR to keep traffic off the public internet.

Edge protection:

• WAF in front of public APIs (AWS WAF or Cloudflare). Rate limiting on auth endpoints.
• DDoS protection (Shield Standard at minimum, Advanced for high-value targets).
• TLS 1.3 enforced, weak ciphers disabled.

Logging and detection:

• CloudTrail enabled across all accounts, logs in a write-once S3 bucket in a separate audit account.
• GuardDuty enabled in all regions you use.
• VPC Flow Logs in critical accounts.
• Alerts on root account use, IAM policy changes, security group changes to high-risk ports.

The output of a hardening pass is a remediated environment plus a runbook. The runbook is the part most security firms don’t deliver — your team has to be able to keep the system in this state, not just visit it once.

Threat modeling at design time

The cheapest security finding is the one that gets caught in design, before code is written.

Threat modeling is a 60-90 minute structured conversation with the engineers building a new feature. We use STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) as a checklist, walking through:

• What data flows through the new feature?
• What trust boundaries does it cross (user → API, service → service, app → third party)?
• What authentication and authorization apply at each boundary?
• What’s the blast radius if a single component is compromised?
• What logging proves abuse after the fact?

A 90-minute threat modeling session at the start of a feature typically prevents 2-5 vulnerabilities that would have shipped to production. The math is overwhelmingly favorable.

For clients on retainer, we run threat modeling sessions on every meaningful new feature. For one-off engagements, we do it on the highest-risk parts of the system (auth, billing, multi-tenancy, anything touching customer PII).

Secure code review: SAST + manual, in CI

Static analysis (SAST) tools catch a specific class of vulnerabilities: known patterns of unsafe code. They miss anything that requires understanding business context, but they’re cheap and they catch real bugs.

Our standard SAST stack:

• Semgrep for custom rules and the OWASP / CWE rule packs. Runs on every PR.
• GitHub Advanced Security if the client is already on GitHub Enterprise. Same vendor, fewer integration headaches.
• Snyk for dependency vulnerabilities (SCA). Configured to fail builds on high/critical with a documented exception process.
• TruffleHog or gitleaks for committed secrets. Configured pre-receive on the repo if you want to be strict.

SAST tools without manual review become noise. The signal-to-noise ratio of a well-tuned Semgrep configuration is around 1:3 — you’ll triage 3 false positives for every real finding. That’s actually pretty good. An untuned configuration is more like 1:30 and the engineers start ignoring the alerts entirely.

For high-value codebases, we do a quarterly manual security review of new code. We look at:

• New authentication / authorization logic.
• Any code that handles user-supplied input that reaches a database, filesystem, or external API.
• Any code that handles money or PII.
• Crypto code (please, don’t write your own crypto).

The review takes 1-2 engineer-days per quarter for most clients. Cheap relative to the cost of a breach.

Tools we actually use

Real working stack, not a marketing list:

Pentest: Burp Suite Pro, OWASP ZAP, Nuclei, ffuf, sqlmap, custom Python scripts for business logic abuse, Caido for newer engagements.

Cloud security: AWS Security Hub, ScoutSuite, Prowler, CloudSploit. For GCP, Cloud Security Command Center.

SAST/SCA: Semgrep, GitHub Advanced Security, Snyk, Dependabot, OSV-Scanner.

Secrets: TruffleHog, gitleaks, AWS Secrets Manager, HashiCorp Vault for clients with stricter needs.

WAF/edge: Cloudflare WAF (our default), AWS WAF for AWS-native shops.

Monitoring/detection: GuardDuty, CloudTrail + Athena for queries, Datadog Security Monitoring for richer clients, open-source Wazuh for cost-conscious ones.

Container scanning: Trivy, Grype, ECR scanning enabled.

The tools are commoditized. The judgment about which findings matter, and the manual work to prove they’re real, is not.

What a security retainer covers

For clients who want a continuous program instead of one-off engagements, we run a $4,000/mo security retainer:

• Continuous SAST/SCA monitoring and triage.
• Quarterly external pentest (focused scope).
• Monthly cloud config review (drift from hardened baseline).
• Threat modeling on new features.
• Incident response on-call.
• Help desk for the engineering team’s security questions.
• Customer security questionnaire support (you’d be surprised how much engineering time these eat).

For regulated industries (healthcare, fintech) or higher-risk surface areas, retainers scale from there. We size to risk, not to vanity.

What we don’t do

• We don’t sell certifications. We help you pass the audit, but we tell you up front that the audit is not the security goal.
• We don’t write 200-page security strategy documents that nobody reads.
• We don’t do FUD-driven sales. If your risk profile doesn’t need a $10K/mo retainer, we’ll tell you. A focused $8K engagement once a year might be enough.
• We don’t promote ourselves as ex-NSA, ex-FBI, ex-anything. Our pentesters are working engineers with 8-12 years of offensive security experience who can also fix what they find.

Pricing summary

• Pentest: from $8K for focused web app, $15-25K for app + cloud + network.
• Cloud hardening engagement: $10-20K, 3-4 weeks, includes runbook handoff.
• Threat modeling session: $1.5K per feature/system, half-day workshop.
• Security retainer: from $4,000/mo. Scales by surface area and risk profile.

Bottom line

Compliance certificates are sales tools. They are not security. The companies that don’t get breached in 2026 are the ones who do the unglamorous engineering work: pentest the application like an attacker would, harden the cloud config, automate dependency patching, threat model new features, and review code with security in mind.

If you want a real security program — not just the certificate — we can start an engagement next week. Discovery call is free.