Minimal Secrecy

The documentation system tenet of minimal secrecy states that most documentation in an enterprise should be accessible to the extended enterprise—all employees and partners—by default. The tenet supports the principle of shared responsibility by isolating and removing sensitive information from general documentation so that it can be opened up to the wider enterprise.

This tenet prevents the formation of a feudalistic information political system whereby the management of information by individual business units or functions “report only limited information to the overall corporation”. (Davenport et al., 1992). In their study of a U.S. electronic firm which was organized along product lines, they noted that each production division head was informally referred to as “barons” and shared the “most limited amounts of data” with their subsidiary head. New information technology, and associated policies have exacerbated this problem. 

Nothing is more detrimental to an enterprise’s DocOps efforts than a dogmatic adoption of the need-to-know principle (NIST, n.d.) by the InfoSec, Information Management, and GRC (Governance, Risk, and Compliance) departments. The need-to-know principle states that users shall only have access to the information that their job function requires, regardless of their security clearance level or other approvals.

The thoughtless enforcement of the need-to-know principle is antithetical to the principle of shared responsibility which encourages sharing and connecting information, as opposed to locking it down in silos behind access control walls.

In Haeckel & Nolan’s (1993) three-prong Corporate IQ model, sharing (in addition to connecting and structuring, which we will refer to in the tenets of connected content, and emergent structure, respectively) is essential. In their study, they noted that “sharing makes possible coordinated effort and, therefore, the benefits associated with teamwork, integration, and extended scope.” and that “getting everyone on the same page in a large business requires an institutional capability to share data”. 

To establish an effective culture of shared responsibility, we need to create the conditions that allow two seemingly unrelated users to benefit, create, and add to an enterprise’s body of documentation without the limitation that they can only collaborate if they belong to the same domain, team, or project. 

But what about personal identifiable information, credit cards, or, perhaps “a secret business strategy to take over the competition”? First of all, this tenet does not suggest that an enterprise’s body of documentation should be published on the public internet. The goal is to make most documentation accessible to members of the extended enterprise by default, and reduce to a bare minimum the information real estate which requires anything other than default access rights. This is what minimum secrecy is all about: open access by default, secrecy by exception.

To add to this, minimal secrecy should not be viewed as a two bucket category system in which one bucket is called ‘default’ and the other one is called ‘secrets’. Such an approach results in everyone creating content in the secrets bucket to avoid accidentally misplacing ‘hush hush’ content into the default one. Instead, minimal secrecy requires a relentless pursuit to document the majority of an enterprise’s truth in a relatively open and secure fashion, extracting out and isolating those few elements which may require secrecy.

Minimal secrecy is not a new idea. Steele (1993) argued that the notion of secrecy is often a fallacy even in most military contexts. He noted that “most secrets start out as non-secrets” and that “it is only after a certain ‘critical mass’ has been reached that some authority decides to classify or restrict information.”

Likewise, minimal secrecy has been in the software engineering world for years. Security sensitive items such as passwords, private keys, and private certificates are kept outside an application’s source code—which may be stored in a public repository such as GitHub. Such sensitive items are stored securely and separately using specialized applications such as secrets and certificate managers. There is no reason as to why regular documentation shouldn’t be subjected to the same principles—to derive similar benefits.

The storing of sensitive information using specialized, advanced mechanisms results in a win-win, both for the InfoSec department—which benefits from advanced security beyond mere access control—and the wider enterprise, which benefits from increased productivity thanks to empowering its workforce with open documentation.

Minimal secrecy also supports the principle of security by design, as opposed to security through obscurity. What this means is that if an enterprise can be compromised by just learning the specifications or information about one or more of its systems—barring, of course, passwords, certificates, access tokens, etc—then, it is not secure by design. Secrecy must never be the mechanism through which an enterprise is secured unless the secret poses a legal, financial or competitive risk.

Minimal secrecy is also a natural property of monorepos. A monorepo (Potvin & Levenberg, 2016) is a software-development approach, popularized by Google in which projects store their source and assets in the same repository so that it is easy for all participants—no matter what domain or which project—to understand how dependencies are implemented, and eventually improve them, fostering collaboration. It is essentially an approach for co-creation, but applied within the software engineering domain.