CrowdStrike Falcon

CrowdStrike Falcon is a package in Primcoat’s software catalog, under Security & EDR. You select it on an image definition, supply its configuration, and Primcoat installs it during the provision stage of every build of that image — before hardening, scanning, and signing.

Why this is a catalog package and not a shell script

Baking an endpoint agent into a golden image is the case where “just install it in the image” quietly produces a broken fleet.

The hazard is host identity. Agents of this class register themselves with a management console, which issues a unique identifier for the machine they are running on. If that identifier is generated at install time and then captured in the image, every instance launched from that image carries the same one — and the console, quite reasonably, treats them as one host reporting from many places. The symptom is not a failed build. It is a coverage gap in the security tool you deployed specifically so that you would not have a coverage gap, discovered weeks later.

This is exactly what a curated catalog is for. The Falcon package carries install logic that Primcoat maintains and versions, a compatibility matrix across supported operating systems, a post-install validation test that runs in the build, and a record of known conflicts with other catalog packages — most usefully with the other EDR agents, which do not coexist happily.

The customer ID is a secret, and it is treated as one

Falcon needs your customer ID to enroll. In Primcoat it goes into the image definition’s variable store as an encrypted secret, and the platform’s handling of it is specific:

• Primcoat encrypts it at rest,
• Primcoat injects it as an environment variable during the build, and never writes it to the image filesystem,
• and a post-build scan verifies that no secret value appears anywhere in the finished image.

That last step matters more than it sounds. A golden image is copied to every machine you run and, frequently, shared to other accounts. A credential baked into one is not a leak in a log file that rotates away — it is a credential distributed to your entire fleet and every account you shared the image with.

What you get

Every image built from that definition boots with the sensor already present and configured — no post-boot bootstrap, no window between an instance starting and being protected, and no configuration-management run that has to succeed before the machine is covered.

The SBOM records the sensor as a component like any other, and the CVE scan covers it.