Security Basics for a Small Software Team

For a software company, identity is the perimeter. The code host, the cloud console, the email domain, the payment dashboard and the password manager are all reachable from anywhere with a username and a second factor. CISA states that phishing is consistently the most cost-effective way for attackers to compromise systems, and that the only widely available phishing-resistant authentication is FIDO authentication (CISA).

Work through identity in this order:

1. Single sign-on for the core apps. In a Hacker News discussion of startup security checklists, Thomas Ptacek, who wrote one of the most cited lists, wrote "I would hold fast on #1 (Single Sign-On)," while accepting that a team can skip it on tools where the enterprise price is unjustifiable. Another commenter gave the reason in one line: without SSO "you have no idea who has access to services" as employees and contractors come and go (Hacker News).
2. Multi-factor authentication everywhere, enforced by policy. CISA tells IT leads to mandate MFA "using technical controls, not faith," because staff who joined in the last few weeks and people who changed phones fall through the gaps. It recommends checking for non-compliant accounts regularly (CISA).
3. Administrators first. The same CISA page notes that in many compromises attackers got a foothold on an administrator's account and from there reached everything the company owned.
4. A company password manager for every system SSO does not cover. CISA's four essentials page points out that a password manager generates, fills and stores complex passwords, so staff remember only one master password. It also says to change default credentials before any product goes into use (CISA four essentials).

CISA's preferred MFA methods, from strongest to weakest, are a physical security key, an authenticator app with number matching, and an authenticator app with a one-time code (CISA four essentials). Text message codes are better than nothing, but they are not on that list. Start with security keys for the people who hold admin rights to the code host, cloud accounts and domain registrar.

The code path is where a software team differs from any other small business. The goal is simple to state: nothing reaches production without passing through a branch, a review and an automated build.

• Protect the default branch. Block direct pushes, require at least one approving review and require passing status checks.
• Run the build, the tests, a dependency scan and a secret scan in CI on every pull request.
• Deploy only from CI, with deploy credentials that live in the CI system and never on a laptop.
• Keep infrastructure in code, so a firewall or permission change is reviewed like application code.

Pull requests, protected branches and CI/CD sit second on the startup list discussed in that Hacker News thread, right after SSO (Hacker News). The NIST Secure Software Development Framework (SSDF) groups the same ideas under two of its four practice groups: "Protect the Software," which means protecting all components from tampering and unauthorized access, and "Produce Well-Secured Software" (NIST SSDF). Black Duck's summary of the framework notes that the Produce group carries explicit expectations for code review and static analysis (Black Duck).

Small teams sometimes treat review as a bottleneck. The SAMM agile guidance argues for review that is "incremental and risk-based," focused on changes and their impact, with solid frameworks and components taking care of as much security as possible (OWASP SAMM Agile Guidance). In practice, reviewers spend their attention on authentication, authorization, input handling and anything that touches money or personal data. Tooling handles formatting, known vulnerable packages and leaked keys.

Most of the code a small team ships was written by someone else. The SSDF puts weight on secure management of third-party components, including knowing where they came from through a Software Bill of Materials and monitoring them continuously for vulnerabilities (Black Duck). That does not require an expensive platform. It requires a few defaults that run on every build.

Secrets deserve their own policy. The short version is that a key that has ever been committed to git history is leaked, even if the commit was reverted, and the only fix is to rotate it.

The remaining common attack paths run through laptops and servers. CISA's task list for a small company's IT lead is short (CISA):

• Patch. Prioritize anything in CISA's Known Exploited Vulnerabilities catalog, which lists vulnerabilities attackers are using in real attacks, and turn on automatic updates wherever possible.
• Back up, then test restores. CISA observes that many ransomware victims had no backups or incomplete and damaged ones, and that scheduling backups is not enough without regular partial and full restore tests.
• Remove administrator rights from user laptops. A user without admin rights cannot install the malware an attacker tricks them into running.
• Turn on disk encryption. CISA notes that phones and Chromebooks encrypt storage by default, while Windows and Mac laptops must be configured to do it.

CISA's Cyber Essentials guide adds an inventory step: maintain lists of hardware and software assets so you know what is in play and at risk, use automatic updates for operating systems and third-party software, and apply security configurations to every asset (CISA Cyber Essentials). For a software team, the inventory includes cloud accounts, domains and every SaaS tool with access to the code or customer data.

CISA also suggests a larger move for teams willing to reshape their setup: retire mail and file servers that run in the office and use cloud services instead, because few small businesses have the time to patch and monitor them (CISA). Most software startups already work this way, which removes a large share of the attack surface before any security work begins.

An incident response plan is the team's action plan for before, during and after a security incident. CISA recommends that leadership approve it in "peace time," that it include an address book usable when the network is down, and that it be reviewed quarterly and after every incident or near miss. It also advises invoking the plan even when an alert looks like a false alarm, because near misses are how the plan improves (CISA).

For a small software team, one page covers it:

1. Who leads during an incident, and who backs them up.
2. How the team reaches each other if email or chat is compromised.
3. The first three actions for the likely cases: a leaked key, a taken-over account, ransomware on a laptop, and exposed production data.
4. Who speaks to customers, and who decides whether regulators, insurers or law enforcement must be told.

Then practice it. CISA recommends quarterly tabletop exercises, which are role-play sessions where one person presents a scenario, such as an employee finding their laptop locked by ransomware, and the team talks through each step of its response (CISA).

When the basics run on their own, a framework helps pick the next investment without guessing. Two are free and fit small teams.

The NIST SSDF is a set of secure development practices drawn from established sources such as BSA, OWASP and SAFECode. It has four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. NIST says the intention "is not to create a checklist to follow," and names cost, feasibility, applicability and automatability as factors in deciding which practices to adopt (NIST SSDF). Because the practices are outcome-based, a team can mark what it already does and list the gaps.

OWASP SAMM is a maturity model. It helps an organization evaluate its existing software security practices, build a program in well-defined iterations and demonstrate concrete improvement. OWASP describes it as technology and process agnostic and risk-driven, because "there is no single recipe that works for all organizations" (OWASP SAMM).

One caution from the Hacker News thread applies to both. A line from a startup security guide quoted there says that a SOC 2 audit "is about documentation, not reality" (Hacker News). A framework or an audit helps you choose and document work. It does not prove the controls work. Test them: try to push to main, plant a fake key, restore a backup, and log in as a departed employee.