The environment section tells vendors what you actually run: languages and package ecosystems, repository and CI systems, how software is deployed, team size and constraints. With it, vendors answer for your reality instead of a generic customer, and you can compare their responses fairly.
Why this section matters most
Most mismatches in security tooling come from the environment, not the feature list. A scanner may handle the main language well and miss the build tool used by one team. A vendor cannot tell you that if you never said which build tool you use.
Give the same description to every vendor. It is also the easiest way to keep the process fair.
What to include
| Item | What to write | Example wording |
|---|---|---|
| Source control | Systems and approximate repository counts | Two systems, a few hundred repositories |
| Languages and ecosystems | Names, with the main five by volume | Ranked list, not a vague "polyglot" |
| Build and CI | Systems used, including exceptions | Primary CI plus one legacy build server |
| Artifacts | Containers, packages, mobile apps, firmware | Container images from a private registry |
| Deployment | Cloud, on-premises, air-gapped parts | Two clouds and one disconnected network |
| Teams | Number of developers, security staff, who triages | Dozens of developers, small security team |
| Constraints | Data residency, access rules, approved identity provider | Customer data must stay in one region |
| Existing tools | What you run today and what stays | Current scanner stays during the pilot |
| Goals | Three outcomes you want in a year | Fewer duplicate alerts, faster fixes, audit evidence |
Use ranges where exact numbers would reveal too much. Vendors can size an answer from a range.
How to gather it quickly
- Ask each engineering lead to list their languages and build tools. A shared form works.
- Pull repository counts from your source control administration page.
- Ask the platform team for the CI systems and any custom runners.
- Ask security and legal for constraints, in writing.
- Check the picture against a dependency inventory from a real repo. Surprises are common.
If you cannot reconstruct the ecosystem list from memory, that is a finding by itself. It also tells you that asset discovery should be a requirement.
A short example
"We have about 300 repositories in two source control systems. By volume, our code is in TypeScript, Python, Java, Go and C#. Most services build in one hosted CI system; two legacy services build on self-hosted runners. We deploy containers to two public clouds. Our security team has four people, and developers triage most findings. Customer data must remain in one region. We want findings in pull requests, a machine-readable inventory, and evidence we can show auditors."
That is about eighty words and answers most of what a vendor needs.
A worked example: a fuller environment description
Here is a longer sample you could adapt, written as a table so vendors can scan it.
| Item | Our answer |
|---|---|
| Source control | Two hosted systems, about 300 repositories, with about 40 archived |
| Languages by volume | TypeScript, Python, Java, Go, C# |
| Package managers | npm, pip, Maven, Go modules, NuGet |
| Build and CI | One hosted CI for most services, self-hosted runners for two legacy builds |
| Artifacts | Container images in a private registry, three mobile apps, one desktop client |
| Deployment | Kubernetes in two public clouds, plus one air-gapped environment for a customer |
| Teams | Roughly 80 developers, four security staff, developers triage most findings |
| Identity | One identity provider with single sign-on and group sync |
| Constraints | Customer data stays in one region, source code must not leave our network without review |
| Existing tools | A current scanner stays active during the trial |
| Year-one goals | Findings in pull requests, a current inventory, evidence for audits |
This is about 200 words of content, and it removes a dozen clarification emails.
Describe the messy parts
Vendors are used to tidy descriptions that do not match reality. Tell them about the awkward parts: the monorepo with five languages, the fork nobody owns, the build that predates your CI, the vendored library copied into three services. These are exactly where tools differ. If a vendor can handle your ugliest case, you will find out in the trial. If you hide it, you find out in month three.
Decide what you will reveal and when
You do not need to share everything in the public RFP. A common pattern is two levels:
- Public section. Languages, ecosystems, scale in ranges, deployment types.
- After NDA. Detailed architecture, network layout and specific repository names.
Use a mutual confidentiality agreement before sharing the second level, and share the same detail with every shortlisted vendor.
Keep the section current
Date the section and note who owns it. When the trial starts, check it again. If something has changed, such as a migration to a new CI system, send a short amendment to all vendors.
Use the section later
The environment description is useful beyond the RFP. It becomes the starting point for your onboarding plan, your coverage targets and your first ninety day review. Writing it well pays off a second time.
Try it yourself
Click through it at your own pace, or open it full screen. See how an inventory lists ecosystems and components, then compare it with the list you wrote from memory.
Quick check
Should we share exact repository counts?
Ranges are fine. Vendors need the order of magnitude to size scan time and licensing questions.
What if our environment is changing?
Say so and describe the target state beside the current one. Ask vendors to respond for both.
Can the environment section double as an onboarding plan?
Yes. The list of repos, ecosystems and constraints is the starting point for rollout waves, coverage targets and the owners you need to contact.
When you evaluate vendors against this section, Safeguard, whose GA capabilities include asset discovery and SBOM and dependency scanning, can be tested on a representative repo through the free scan at https://gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
