Sectemplates, document packs for the security programs a small team has to run

The problem is having no programme at all

Sectemplates exists because a small company often has security obligations before it has a security function. The README describes the audience as infosec professionals, and startup engineering teams lacking a security team, and the stated aim is to give them templates to help bootstrap their programs.

The scope is deliberately limited to starting points. The focus is on five kinds of artefact: preparation checklists, runbooks, programs and their associated processes, useful security metrics, and document templates. That list is the real content of the project, and it describes the shape of a security programme at the level of process rather than tooling.

What this is not is a platform or a tool. The top level of the repository contains no source code: it holds a README.md, a SECURITY.md, an announcements/ directory and one directory per programme pack, with bug-bounty/, external-penetration-testing/, incident-response/, security-exceptions/, security-partners/ and vulnerability-management/ as the six packs. The primary language of the repository is not even recorded as a known one, which is consistent with a collection of documents rather than code.

There is nothing to install and nothing to run. The deliverable is text you read, argue with and adapt, and the value is that the argument starts further along than a blank page.

Six packs, one function each

Each directory in the repository is a programme pack with a stated goal, and the goals are written tightly enough that you can tell whether a pack is for you.

The bug bounty pack is for establishing a bug bounty program, and the README says it includes alignment with stakeholders, working with a vendor, establishing a private bug bounty, and ultimately moving to a public one. The external penetration testing pack contains what is needed to scope a first pentest, work with a vendor, execute it, and get the report types you need from an external tester, for a product or infrastructure level test, with a process to carry forward for later engagements.

The incident response pack is for establishing a functioning security incident response program, the vulnerability management pack for a fully functioning vulnerability management program, and the security exceptions pack for a functioning security exceptions program. The security partners pack is the newest and has a different shape: the goal is minimal information to establish a functioning and impactful security partner programme, adopting a security partnership model with a repeatable process to scale up as needed.

That last one is the most distinctive. A partner programme is a different relationship from a bug bounty: it is about working with a defined set of external researchers or firms rather than soliciting reports from anyone. The pack treats it as a separate discipline rather than as a variant of bounty hunting.

The bug bounty pack refuses to pick a vendor

One line in the README deserves more attention than the rest. The bug bounty pack is not sponsored or influenced by any particular bug bounty vendor and is neutral to vendor biases and influence.

That is a deliberate editorial stance in a category where templates are usually a vendor's marketing. A bug bounty platform has an obvious interest in a company adopting a specific programme with a specific scope model, a specific payment structure and a specific platform contract, and a template that quietly encodes those choices is advertising rather than guidance. The README is explicit that this one is not that.

The consequence for the reader is that the pack gives you the parts of a programme that do not depend on who runs it: how to align stakeholders on scope, what a private programme looks like before you open it up, how to move to a public one, and what a report and a triage process need to cover. Choosing the platform is left as an explicit decision rather than being decided for you in a template.

The security partners pack carries the same neutrality in spirit. Its goal is stated as minimal information to establish a functioning and impactful programme with a repeatable process, which is a process description rather than a product recommendation.

Working with the packs is editing work

There is no install step to describe, because there is nothing to install. The material is reached through the site at www.sectemplates.com, and the README points to an about page there, with the site's own framing of the collection and its audience. The repository is the same content in version-controlled form, with a SECURITY.md alongside it and an announcements/ directory for release notes.

The realistic way to use a pack is to read it against a specific situation and rewrite it. A vulnerability management programme, for instance, has to name the systems you actually run, the scanners you actually run, the severity scheme your organisation already uses and the people who can accept a risk. A template cannot know any of that, so what you get from the pack is the structure of the programme and the questions to ask, and what you have to supply is every specific answer.

The preparation checklist idea is the one most likely to pay off, because a checklist is the artefact that survives contact with a small team. Runbooks and metrics have the same property. Programs and processes, by contrast, are the hardest to adopt unchanged, because a process that names people and decisions has to be rewritten for the organisation that will run it, and the pack's value there is in telling you what has to exist rather than in telling you what to write.

The metrics in the list deserve a caution. A metric without a baseline is a number, and the useful question about any security metric is what decision it changes.

The licensing excludes exactly the use case a template attracts

The licence is the part of this repository that most deserves a careful reading, and it is not a standard open source licence.

The README states that content is free to use for personal and commercial purposes, with the exception of including it in a product that's for sale or a product developed based on it, and it says to see the licensing under each project for details.

That exception is narrower than a conventional copyleft and broader than a permissive licence. Using the templates to run your own security programme is fine, whether you are a consultant or an in-house engineer, and you can charge for the work of implementing them. What is not fine is packaging the templates themselves into something you sell, and also the more diffuse case of a product developed on the basis of them, which the wording reaches.

Two implications follow. The first is that the terms are per project rather than uniform, which the README says twice, so the licence note under the specific pack you are using is the document that governs. The second is that anyone contemplating a commercial security management product should look at those terms before assuming the templates are a free component of their offering.

The repository's own licence field is recorded as unknown, which is consistent with the source licence being a custom file. The practical advice is to read the licence text in the pack directory rather than relying on the summary above, which is the summary, not the licence.

Where these templates are the wrong tool

There are three situations where a template pack is the wrong answer.

The first is a mature programme. If your organisation already runs a bug bounty, an incident response process and a vulnerability management cycle with real metrics and a real retrospective history, a template adds nothing except the risk that someone reads the pack as a description of how you do things.

The second is where the gap is technical rather than documentary. Templates cannot give you a log pipeline, a detection rule, a hardening baseline for a specific platform, or a way to prove that your identity provider is configured correctly. A pack can tell you that a programme for vulnerability management should exist and what shape it takes, and it cannot tell you whether your container images are patched.

The third is compliance work presented as a template problem. A regulator or a customer asking for evidence of a programme is asking whether you do the things, not whether you have documents that say you do them. Filling in a checklist with untrue answers produces a document that fails on first inspection.

There is also the timing point. These packs are most useful at the moment a team has been given the responsibility and has nothing, and least useful later, once the real programme has diverged from the template because reality did. That is not a criticism of the templates, it is what a starting point is for.

Editorial conclusion

Sectemplates suits an engineer who has just been handed security responsibilities with no team, no process and no documents, and who needs a defensible starting shape for a programme this quarter. It does not suit an organisation that already has a mature programme, and it does not suit anyone planning to turn the content into a commercial product. Before you adopt a pack, read the licensing note under that specific project, because the repository says the terms are per project, and expect to rewrite: these are starting points for preparation checklists, runbooks and document templates, not policies you can publish unchanged.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. securitytemplates/sectemplates on GitHub