A Security Mindset for Team Leads

"Is this secure?" is a question a lead hears from managers, customers and interviewers. A weak answer is "we use HTTPS" or "the security team handles it". A good answer shows a routine: a short threat model before building, safe defaults, checks in review, regular access reviews, and a clear way to report and handle problems. This lesson gives that routine in simple steps.

Read Lesson 0 first for the answer shape. Dependencies are covered in Lesson 1; this lesson goes deeper on the security side. For the technical attacks and fixes see Full-Stack Lesson 31 (server-side security) and Browser Lesson 7 (the browser security checklist). For review habits see Lesson 3, and for incidents see Lesson 4 and Lesson 6.

Everything here is common practice and opinion. It is not legal, audit or compliance advice. Your company may have rules (and a security team) that come first.

Words used in this lesson

• A threat is something that could harm the system, such as a person stealing a login token.
• A threat model is a short, structured look at a system to find what can go wrong and what to do about it.
• A trust boundary is a line where data moves between parts that trust each other differently, for example from the user's browser to your server.
• STRIDE is a memory aid for six kinds of threat: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege (explained below).
• Least privilege means giving each person or program only the access it needs, and nothing more.
• Secure by default means the safe choice is what you get if you do nothing.
• A secret is a credential: an API key, a password, a token, a private key.
• A supply chain is everything your software depends on and the way it is built and delivered: packages, build tools, CI, registries.
• Provenance is verifiable information about where and how an artifact was built.
• A vulnerability is a weakness that someone can use to cause harm. A CVE is a public ID for a known one.
• Disclosure is how a weakness is reported and made public. Responsible disclosure means the reporter and the owner agree on a fix before details are made public.
• SECURITY.md is a file in a repository that says how to report a vulnerability.
• An access review is a regular check of who has access to what, and removal of what is no longer needed.

The lead's job in security

You cannot review every line for security. Your job is to make the team's defaults safe and to make the right thing the easy thing. Four questions to keep in mind:

1. What are we protecting? Customer data, money, accounts, uptime.
2. Who could attack it, and how? Strangers on the internet, a bad dependency, a leaked key, a tired employee, a former employee.
3. What stops them? Controls that are built in, not remembered.
4. How will we know, and what will we do? Logs, alerts and a response plan.

The OWASP Threat Modeling page frames the same thing as four questions (from the Threat Modeling Manifesto): What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? I read this directly.

Threat modelling in 30 minutes

OWASP's cheat sheet says threat modeling is "a structured, repeatable process", ideally done early (such as in design) and kept up to date, not done once. It also says there is "no universally accepted industry standard", and that the data flow diagram is the most common way to model a system. A short session can follow those four questions. This plan is my own:

STRIDE, as the cheat sheet gives it

I read this table in the OWASP Threat Modeling cheat sheet. It says STRIDE was originally developed by Microsoft employees.

A tiny example (invented for this lesson): a "password reset by email link" feature.

The cheat sheet lists four possible responses to a threat (credited to Adam Shostack): mitigate (reduce the chance), eliminate (remove the feature), transfer (give contractual or financial responsibility to someone else; it does not itself reduce the chance) and accept (decide to live with it, and write down why).

Other points from the cheat sheet that matter to a lead:

• Rank, but do not pretend it is exact. Ranking is often likelihood times impact, but both are hard to calculate.
• Do not add techniques only to look thorough. The cheat sheet also names other methods (attack trees, misuse cases, LINDDUN for privacy, PASTA, OCTAVE, VAST) and says to state why each technique fits.
• Developers often lack security training, and the cheat sheet suggests inviting a security person to the session and keeping training regular.
• Review with everyone, not only developers. Product and operations know things you do not.

Secure by default

A good default beats a good reminder. Ideas, mostly from the cheat sheets I read, in a lead's language:

• Make the safe path the easy path. A project template that already has the secure settings is better than a wiki page that explains them.
• Deny by default. New endpoints require login and a permission check unless someone says otherwise on purpose. (This is my own rule of thumb. The Authorization cheat sheet has a section on enforcing least privilege, which is related.)
• Use well-known libraries and frameworks for hard things (login, sessions, crypto). Do not invent your own.
• Validate input and encode output. The attacks and fixes are in Full-Stack Lesson 31 and Browser Lesson 7.
• Turn on the protections your platform offers. Branch protection, required reviews, two-factor login, automatic dependency alerts.
• Reduce the attack surface. Remove features and endpoints that nobody uses. An unused admin page is a risk with no benefit. This matches "eliminate" in the threat responses.
• Make danger visible. A flag named allowAnyOrigin shows its own risk. A flag named fast hides it.

Dependencies and supply chain hygiene

Lesson 1 covered how to choose a package. Security adds the question: how do we stop a bad or broken package from reaching production? The OWASP Software Supply Chain Security cheat sheet has sections on source code threats (peer reviews, secure config of version control), dependency threats (assess suppliers, monitor dependencies, lockfiles and pinning), build threats (harden build tools, code signing, provenance, isolated builds) and deployment threats. I read it directly. The npm cheat sheet adds practical steps.

Habits for a Node team

Each of these appears in the OWASP npm cheat sheet unless I say otherwise:

1. Enforce the lockfile. Use npm ci in CI and builds, so the installed versions are exactly the ones in package-lock.json and any mismatch stops the install.
2. Consider ignoring install scripts. --ignore-scripts (or ignore-scripts=true in .npmrc) stops third-party packages from running scripts when installed. Allow only the packages that truly need them.
3. Audit dependencies. npm audit checks for known vulnerabilities. Run it in CI.
4. Automate updates. The Scorecard check Dependency-Update-Tool looks for Dependabot or Renovate, and describes the risk of old dependencies as High.
5. Beware of fake names. The cheat sheet describes typosquatting (a malicious package with a name like a popular one) and slopsquatting (a package name that an AI assistant invented, which an attacker may then publish). Check that any new package exists and has real history before installing it.
6. Use two-factor login and short-lived tokens for publishing. The cheat sheet recommends trusted publishing (short-lived, workflow-specific credentials from your CI), which also produces provenance automatically.

Let me show a few of these for real. This is a throwaway project in a scratch folder.

npm init -ynpm install semver --ignore-scripts

added 1 package, and audited 2 packages in 547msfound 0 vulnerabilities

Enforcing the lockfile. I changed the wanted range in package.json from ^7.8.5 to ^6.0.0 without updating the lockfile, then ran npm ci:

npm ci --ignore-scripts

npm error code EUSAGEnpm errornpm error `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.npm errornpm error Invalid: lock file's semver@7.8.5 does not satisfy semver@6.3.1

That is the point: the build stops instead of quietly installing something different.

Check that a package exists (against slopsquatting). I tried a name the cheat sheet gives as an example of an AI-invented one:

npm view node-fetch-promise name

npm error code E404npm error 404 Not Found - GET https://registry.npmjs.org/node-fetch-promise - Not foundnpm error 404npm error 404  'node-fetch-promise@*' is not in this registry.

At the time I ran it, that name was not in the registry. This can change: anyone could publish a package with that name later. So a missing name is a warning, and an existing name is not proof of safety. Check the repository, the history and the maintainers as well.

Provenance. npm can show whether a published version carries a build provenance statement:

npm view semver dist.attestations

{  url: 'https://registry.npmjs.org/-/npm/v1/attestations/semver@7.8.5',  provenance: { predicateType: 'https://slsa.dev/provenance/v1' }}

This shows that the registry holds a provenance attestation for that version (an SLSA provenance statement, as the type URL says). It does not by itself prove the package is safe. It says where and how the package was built. The next command is meant to check signatures for the whole project:

npm audit signatures

npm error Failed to download

It failed in my sandbox, so I cannot show you a verified result. It may need access to a signing-key endpoint that my network blocks. I am not claiming a reason, only that I did not get a result. Run it on your own machine and read what it says.

OpenSSF Scorecard

OpenSSF Scorecard is a project that runs automatic checks on a repository and gives a score. In Lesson 1 we used it to judge outside packages. A lead can also use it on their own repositories as a free checklist. I read the check descriptions directly. A few that matter to a team (risk levels as the document states them):

Two details I find useful:

• Token-Permissions says the best setup is read-only permissions at the top of each workflow file, with write permissions declared only on the job that needs them. It gives examples of what an attacker could do with broad write access, such as changing the result of required checks.
• Branch-Protection notes that some settings need an admin token to be read, so a score from outside may undercount. Scores are a signal, not a verdict.

Secrets

Many incidents start with a secret in the wrong place. The OWASP Secrets Management cheat sheet starts by saying that many organisations have secrets hardcoded in source code or scattered through configuration files. What I take from it for a team (the cheat sheet is long; I read the headings and the parts quoted here):

• Centralise and control. Keep secrets in one managed place with access control, not in code, tickets or chat.
• Apply least privilege to the secret store too. The cheat sheet says engineers should not have access to all secrets.
• Audit. At minimum: who asked for a secret, whether it was approved, when it was used, when it expired, failed access attempts, and who changed it.
• Plan the life of a secret. Creation, rotation, revocation and expiry each have a section. A secret that can never change is a long-term risk.
• Prefer short-lived credentials. The npm cheat sheet says long-lived tokens "can be compromised, accidentally exposed in logs, or require manual rotation", and recommends short-lived ones.
• Do not log secrets. The Logging cheat sheet has a list of data that should not be logged (sensitive personal data, commercially sensitive information and more).

A lead's small rules (my own):

1. Scan for secrets before they reach the main branch. Use your platform's secret scanning or a pre-commit tool.
2. If a secret leaks, rotate it first, then investigate. Deleting the commit does not help, because it may already be copied.
3. Separate secrets per environment and per service. The cheat sheet notes that when services share the same secret it is hard to find the source of a leak.
4. Know where each secret lives and who owns it. A short list is enough.

Access reviews and least privilege

Least privilege means each person and each program gets only what they need. The Authorization cheat sheet says it is easier to grant extra permission later than to take it away, so plan this early.

An access review is a calendar event, not a project. A simple version (my own):

1. Every quarter, list access to the places that matter: source repositories, cloud accounts, production data, CI/CD, secret stores, monitoring and admin tools.
2. For each person, ask: do they still need this for their current work?
3. Remove what is not needed. Remember contractors, interns and people who changed team.
4. Check service accounts and tokens too. Who owns them? When do they expire?
5. Check the leaving process. When someone leaves, who removes access and how quickly?
6. Write down the result and keep it. Auditors and your future self will want it.

Rules that help:

• Give access to groups and roles, not individuals, so that it is easy to review.
• Make production access rare and logged. Not everyone needs write access to production data every day.
• Separate duties for the riskiest actions (for example, a second person approves a production database change).
• Break-glass access for emergencies should be possible, but loud: logged and reviewed afterwards.

Incident response and disclosure policy

Things will go wrong. Lesson 4 and Lesson 6 cover incidents and blameless learning. Security adds two points: someone outside may find the problem first, and some information must not be public yet.

Have a SECURITY.md

The Scorecard Security-Policy check looks for a file named SECURITY.md (case-insensitive) and says it can tell users "what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible". The check awards points for a valid contact (an email address or a link for reporting), free-form text beyond that, and for describing the process and disclosure timelines. This is what I read in the check text. A small outline (my own):

# Security policy## Reporting a vulnerabilityPlease do not open a public issue. Email security@example.com(or use the "Report a vulnerability" form), and include steps to reproduce.## What to expect- We will acknowledge your report within 3 working days.- We will keep you updated and aim to fix serious issues within 30 days.- We will credit you in the release notes if you wish.## Supported versionsOnly the latest major version receives security fixes.

The email and the time promises above are placeholders. Only promise what your team can do. A silent inbox is worse than no policy.

The charlax list also links an article on security.txt (a small file at a known web address that tells researchers how to contact you). I did not read it, so I only know it from its title.

Responsible disclosure

The OWASP Vulnerable Dependency Management cheat sheet describes two ways a researcher may report a weakness:

• Responsible disclosure: the researcher works with the owner, and a CVE is issued so the problem has a public ID. The cheat sheet says that if the researcher gets no reply in 30 days, they often go on to full disclosure.
• Full disclosure: the researcher publishes all the details, sometimes including an exploit.

That 30-day figure is how the cheat sheet describes common practice, not a law. The lesson for a lead: answer reports quickly, and have someone named who reads the inbox.

A simple security incident routine (my own)

1. Name an incident lead and open one place for notes.
2. Contain first. Revoke the key, disable the account, roll back the release.
3. Preserve evidence. Keep logs, and do not wipe what you need to learn from.
4. Tell the right people. Your manager, the security or legal contact, and, where the law requires, customers or authorities. The rules differ by country, so involve the people who know.
5. Fix the cause, not just the symptom.
6. Write a blameless review and make the follow-ups tickets with owners.

Security in code review

You do not need a separate security process for everything. Add a few questions to the review habit from Lesson 3:

The OWASP supply chain cheat sheet lists peer review as a relatively low-cost technique that deters and detects problems, and says it should happen before code is merged. Two lead habits:

• Mark security comments clearly (for example "Security:") so they are not mistaken for taste.
• Require review from a second person for risky areas (authentication, payments, permissions, CI configuration). Branch protection makes it automatic.

Training the team

The OWASP Threat Modeling cheat sheet says developers often lack security knowledge and recommends regular, tailored training and involving security people. In practice (my own suggestions):

• Use your own code. A one-hour session on a real bug from your repository teaches more than a generic video.
• Run a small threat modelling session for every big feature, and rotate who draws the diagram.
• Read one public incident per month. The danluu/post-mortems list (see Lesson 6) has many, including security-related ones. Ask: which control would have stopped this in our system?
• Keep a short checklist next to the pull request template, and update it when something slips through.
• Reward early reports. If a person says "I think I leaked a key", thank them. People hide mistakes if they are punished (see psychological safety in Lesson 8).
• Name a security champion in the team: someone with extra interest who connects to the security team. Rotate it.

Try it

1. STRIDE the login. Pick one STRIDE letter and name a threat to your own login page. Answer: For example, Spoofing: someone reuses a stolen session token. Response: short session life, rotate tokens on login, detect a use from a new place. Or Denial of service: many failed logins lock a real user out. Response: slow down by IP and by account without locking forever.

2. Lockfile. What should CI run instead of npm install, and why? Answer: npm ci, because it installs exactly what the lockfile says and stops if package.json and the lockfile disagree (as in the output above).

3. A leaked key. A developer pushes an API key to a public repository and deletes it in the next commit. Is the problem over? Answer: No. The key may already be copied and is still in the history. Rotate the key first, then check where it was used, then add scanning so it does not happen again.

4. Access review. Write three questions you would ask in a quarterly review. Answer: Who still has production access, and do they need it? Which service accounts and tokens exist, and who owns them? Did every person who left this quarter lose access, and when?

Interview questions

Key takeaways

• A lead's security job is safe defaults, small habits and a clear plan, not knowing every attack.
• A 30-minute threat model: draw it, walk it with STRIDE, choose mitigate, eliminate, transfer or accept, and make tickets.
• Use npm ci, audits, update tools and care with new package names. Provenance says how something was built, not that it is safe.
• OpenSSF Scorecard is a useful free checklist for your own repositories. A score is a signal, not proof.
• Keep secrets out of code, give them owners, rotate them, and rotate first when they leak.
• Review access every quarter. Give the least access that works.
• Have a SECURITY.md you can honour, and a routine for incidents. Involve legal and security early.
• Add a few security questions to code review. Train with your own code and reward early reports.
• I read the OWASP and Scorecard pages directly, ran a few small npm commands (one of them failed), did not run Scorecard, and know the three charlax security links only by title. Adapt this to your company.

What's next

Next: Rules for AI-assisted coding on a team, Lesson 15. Practise: run a 30-minute threat model on the next feature you build, with the team at a whiteboard, and turn the top three threats into tickets with owners.