The security practice registry
Are we merely historians of our own infrastructure?
The past and present wilt—I have fill’d them, emptied them.
And proceed to fill my next fold of the future.
I don’t think Whitman would have made much of a CISO. We struggle precisely because we live at that juncture between the past and the future - existing practices and planned ones. Our present is almost impossible to empty; for us, the present is little more than the accumulation of past practices we firmly grasp, fearful of letting go of what was won with such difficulty. We hoard the past, and in doing so we constrain the future. What was hard-won becomes untouchable, and the result is not stability but inertia - an environment where new approaches struggle to take hold because the old ones are never truly released. Our resources are finite, yet our desire - our need to respond to new threats - is unlimited.
In this post, I want to reflect on the issue of balancing historical practice with new demands, through the lens of the term security practice registry, and three possible definitions for it. Each offers a similar but distinct framing for historical practice that can help inform and guide future actions. Each definition expands the scope of the registry - from institutional memory, to sector coordination, to ecosystem trust.
Let’s start with the control plane. In this framing, a security practice registry acts as a centralized authoritative database where the organization logs and tracks exactly which security controls, policies, or practices are active across various units. It asks “what are we carrying?” In one sense, it is an institutional risk and governance ledger. For most of us, especially in higher education, this is the space where GRC tools live. At a larger scale, globally matrixed corporations use continuous controls monitoring platforms - I’m thinking of a tool like Panaseer (which I have no personal experience with). In this market, the tool logs both vulnerabilities and whether specific controls have been implemented in discrete business units across the enterprise.
What’s lovely in this approach is that instead of a generic compliance checklist, this registry maps reality. I find this attractive because it articulates what we’re actually doing (and where) even if it rarely touches on why. One need not “speak truth to power” but simply describe the situation on the ground. Observation over analysis.
Alternatively, we can view a security practice registry as a form of collective telemetry, a sector-wide defense repository. It asks “how we compare and calibrate?” When applied to a community or industry sector (like a sector-specific Information Sharing and Analysis Center, or ISAC), a security practice registry functions as a collaborative blueprint. Rather than sharing volatile threat intelligence data like changing IP addresses or file hashes, organizations use a registry to share their structural defensive postures. It catalogs the specific configurations, architectural designs (such as protected, anonymous networks for research), and mitigation steps that peer institutions are successfully deploying against targeted threats. It allows a sector to baseline what “best practice” looks like in a complex environment. But caution is warranted; do not confuse comparative and normative risk1.
Finally, we can continue our outward expansion to define a security practice registry as a supply chain and software registry architecture. Here we ask “what we unknowingly import into the future?” In software engineering and DevOps (such as managing open-source package managers like npm, PyPI, or DockerHub), the phrase refers to the security protocols enforced by a platform registry. This includes logging cryptographic signing practices, verifying software provenance (like Software Bills of Materials, or SBOMs), and ensuring a transparent, auditable trail of code custody to prevent software supply chain attacks.
For each framing we have plenty of examples, the ones provided here are merely illustrative. GRC and CCM tools serve as the institutional risk and governance ledger. Sector-wide telemetry emerges through platforms like CIS CSAT, MITRE ATT&CK Mitigation Matrix, and D3FEND, which encode shared defensive patterns against common threats. At the supply chain layer, Sigstore, OpenSSF Scorecard, and secure container registries (e.g., Docker Scout, AWS ECR) extend this logic outward, enforcing provenance by requiring artifacts to map to SBOMs.
One object class, “security practice registry”, three different instantiations of the object, each with differing properties, but all three offer value to us as security practitioners. More plainly, all three of these at first glance look like mere technical artifacts, when in truth they serve as governance primitives. That is, they shape decision-making by structuring visibility, not by prescribing action2. Collectively they ask “how does this help us decide what to keep versus discard?”
It’s worth pointing out that by calling these governance primitives, I’m using “governance” in two ways. The immediate conclusion is that it refers to formal institutional governance processes - and that’s correct. But it also refers to the kind of managerial governance we exercise over our office activities, the agency our organizations have invested in us as practitioners. I won’t fully untangle this knot here, but it is worth reflecting on how to balance those two domains of governance. I suspect that for expediency, we all try to expand the latter and minimize the former. In reality, the decision tree for this is cultural and organizational, and not a function of expertise or practice logic.
Be that as it may, by using these artifacts - these three forms of registry - to inform governance decisions, we begin to wrestle historical and current practices to the ground. They show us where and at what scale actual risk exists within our ecosystems. Importantly, each reveals a different type of risk.
The supply chain and software registry is largely a risk of the unknown. It shows us gaps in our knowledge (or at least visibility) about the products we introduce into our ecosystem. An incomplete SBOM or a poor Scorecard measure suggests the need to more deeply interrogate a product. Being an outlier in the space of collective telemetry could mean you’re the only one doing something right. But more likely is that you’ve recreated the wheel or fallen down a rabbit hole. Innovation and creativity are valuable but sometimes you just need to use a hammer, and not engineer a nail insertion protocol. Here the risk is that delta between you and the rest of the world - a signal that needs explaining. This is the risk of isolated deviation. While our scientific workflows are uniquely open, the underlying technical primitives - identity management, network routing, credential storage - are not. Conflating unique research with unique infrastructure is how we fall down these customized rabbit holes.
Of course, the institutional risk and governance ledger gives you a literal map, the topology of practice risk in your organization. It allows you to ask “why isn’t MFA being used in a specific unit?” or “why does one research lab have 80% of our policy exemptions?” True, this is not the same as the classic risk register, i.e., an inventory of threats, but it reveals where we are weak thus showing where resilience is lacking. I would label this the risk of permeability, where your internal enterprise fabric is structurally thin.
Exploring the notion of a security practice registry reveals a reusable model where risk visibility and governance influence are emergent properties. What I find attractive in this formulation is how we can use one mental model to surface multiple forms of risk. This allows us to shift the past from a burden to be carried to a tool to inform planning and governance. In evaluating this or any model we should always pose the question, “what does this let me ask that I couldn’t ask before?” Critically, this model creates visibility and thus a pressure to act. But governance determines whether that action is thoughtful or reactive. Visibility is not the same as wisdom; registries create the former, while governance must supply the latter.
Whitman believed that to grow, a person must possess the radical capacity to shed their former selves, their past mistakes, and even their hard-won achievements. If you keep your vessel full of the past, you have no room to receive the future. History should no longer be a weight holding us back, but through the use of practice registries it becomes a ladder helping us better survey our landscape and make future decisions based on that wisdom. History becomes the embodiment of traceable wisdom3.
I think this happens more than we realize. Historically, institutions looked at their peers' low self-assessment scores and felt a false sense of security based on comparative risk (“everyone else is failing too”). In doing so, they completely ignored the absolute normative risk of non-compliance, resulting in the broad winking and nodding we saw with SPRS scores that ultimately forced the federal government to mandate CMMC.
You’ll note that I’m trying to inject a deliberative step here. It’s tempting to view the intelligence coming from any of the three framings as initiating action (e.g., “see, they’re not using MFA, let’s force it on them.”) And that may ultimately be the result. But what I’m encouraging here is for you to pause and ask, in partnership with governance, the question of why something is what you’ve discovered. These registries increase visibility and visibility increases pressure to act, yet I am advocating deliberation through governance before action. This deliberation is what allows you to inject thoughtfulness into your operational workflow - essentially, to step for a second off the treadmill.