Abstract
With the rise of cybersecurity incidents, there is more attention being paid to software development systems and build pipelines. Among the varied advice from specialists on ways to prevent attacks is an investment into hardening software delivery pipelines and protecting code integrity. To that end, products are being marketed to scan for secrets and credentials as part of the build process as a solution to supply chain vulnerabilities.
Companies that purport to do these things are gaining increasing visibility. While the practice that these products are surfacing are valid areas for concern and remediation, these are a symptoms of the problem, not the problem itself. Thus, the approaches being touted will not have a meaningful impact on the larger threat surface but will instead continue to facilitate the false sense of security that is leads to gaps between subjective responses and objective research.
Introduction
In Gartner's How Software Engineering Leaders Can Mitigate Software Supply Chain Risks, it is reported that by 2025, nearly half (45%) of organizations worldwide will have experienced attacks on their software supply chains. The report goes on to point out several findings and "top practices" to begin mitigating supply chain security risks in software development and delivery. One of the practices given is "secrets scanning and management," categorized in the "delivery pipeline" stage of software development.
This report is, in fact, cited in the marketing materials for many new products offering "secrets scanning" as a prime deliverable of a [partial] cybersecurity solution. However, as is often the case, this citation and these products are a symptom of the larger problem itself, which is a lack of understanding of software development and cybersecurity as a whole.
Background
What is missing is the context for the best practice. "Secrets scanning" is only the first half of the recommended practice; scanning is only one of three (3) best practices given at the delivery pipeline stage. The delivery pipeline stage is one of three (3) stages identified, each with another top three (3) respectively.
The graphic included in the Gartner report is below.
If one were to stop reading at the first provided graphic –consequently on page 3 of the Gartner report –they would come to the conclusion that seems to be the common understanding: scanning for secrets should happen during the delivery (CI/CD) process. (There is also the implication that it currently does not happen.) As a fact, yes, it should happen –but the point that it should and is not happening is still a symptom.
If a person was not deeply experienced in cybersecurity or software development, the other items on that visualization would be confusing. What constitutes "strong version control policies?" What is a "component registry" and which ones are trusted? What is a "third-party risk" and how should it be managed? How is something "signed" or "hashed?" What does "hardening" mean? What is included in "CI/CD pipelines" and what do "CI" and "CD" mean? What is "least privilege access" and how is it controlled? "Machine identity?" What is an "anomaly" and how would it be detected, who decides, and who responds in what way?
In light of the confusion, "secrets scanning" is largely the only one that seems to make sense. Scan the code for secrets when it's being built? We can do that.
What is a secret?
Secrets are digital authentication credentials, including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.
Secrets management refers to the tools and methods for managing secrets. While secrets management is applicable across an entire enterprise, the terms "secrets" and "secrets management" are referred to more commonly in IT with regard to DevOps environments, tools, and processes.
Secrets can include:
User or auto-generated passwords;
API and other application keys/credentials (including within containers);
SSH Keys;
Database and other system-to-system passwords;
Private certificates for secure communication, transmitting and receiving of data (TLS, SSL, etc.);
Private encryption keys for systems like PGP; and/or
RSA and other one-time password devices.
Context
Gartner next provides the following graphic:
For a non-technical person, if one had continued reading, this graphic would add more confusion. "Internal and External Code," "Delivery Pipeline," and "Operating Environment" are not shown in this software supply chain. Worse, "hardcoded secrets" is pointing to a "Develop" stage, which is not the same as the "Delivery Pipeline" in the previous image. "Certificates": are tied to "Deploy" –but the certificate is also a secret. Which one is right?
The short answer is...."both." This is where one must understand context.
Gartner report basis
One of those facts is the basis of or catalyst for the Gartner report. This report was not produced as a byproduct in response to data gathered that indicated that these are the areas responsible for most attacks. It does not suggest that nor encourage any such conclusion.
This report was created in response to specific security concerns that Gartner encounters in client inquiries. Those are:
Compromise of continuous integration/continuous delivery (CI/CD) systems;
Injection of malware into legitimate software; and
Inclusion of vulnerable and malicious dependencies.
It may seem like a literary exercise or semantics to cite these details, but it is important to highlight that these are the things that Gartner is asked about –not that they are NOT risks, but that they are not necessarily the largest risk being exploited.
This report was meant to highlight best practices for the software supply chain. As it happens, this is not a new list or even new research. It is a reiteration of best practices that already exist in publication –and should already be followed. The fact that Gartner's clients have questions in this area shows that these practices are not known and/or followed, and the lack thereof could be contributing to the increase in [successful] cybersecurity attacks.
Today's business professionals and this generation of engineers/developers may not have received training in cybersecurity and/or secure development. With that possibility, they would not realize that best practices in secure development are published freely and kept current with evolving technologies. Scanning for secrets has always been included in these recommended practices. It is merely the recent buzz around the terminology and process that has increased visibility and led to client inquiries to Gartner.
Disconnect
Gartner's report is not suggesting that the public is in need of new products to address each best practice in the report, although that seems to be a prevalent interpretation. It is highlighting that the current development population is not employing those best practices.
Whether there is a lack of awareness of secure practices or a cross-organizational ignorance in cybersecurity, guidance for secure development has been established for approximately twenty (20) years:
OWASP (The Open Web Application Security Project) was announced on September 24, 2001, providing articles, methodologies, documentation, tools, and technologies in the field of application security.
On January 15, 2002, Bill Gates and Microsoft launched the SDL (Security Development Lifecycle).
On July 17, 1995, NIST (National Institute of Standards and Technology) established guidance on cryptography and has entire project groups devoted to specific areas of information security.
For at least as far back as Visual Studio 2005, the standard code analysis feature not only scanned projects for hard-coded strings of any kind upon demand, but also warned developers in real-time as part of the development experience in the IDE.
The use of associated tools, publications, and referential bodies should be basic development practices, all of which inherently address the "secret scanning" recommendation –and many other best practices.
In fact, many of the publications and groups are referenced in existing standards, such as PCI DSS which is the standard governing any company that accepts payments. That standard refers to "OWASP" and "NIST" multiple times throughout.
Sonatype recently published 2021 State of the Software Supply Chain. It reports the findings from surveying industry professionals in regard to their cybersecurity posture, and then conducting assessments to verify the responses given. Their research found that there is a disconnect between independent subjective surveys of organizations compared to objective assessments of the same. Despite the data proving otherwise, people believe they are doing a good job remediating defective components and indicated that they understand where risk resides.
Objectively though, the research showed that development teams lack structured guidelines and frequently make suboptimal decisions with respect to software supply chain management. Further, they do not have intelligent tooling to ensure quality outcomes.
Reconciling these subjective perceptions with objective reality is the first step in helping organizations achieve promised efficiency gains, reduced threats and vulnerabilities, and better dependency management.
Conclusion
While the attention that cybersecurity and potential mitigating practices is receiving is progress, rushing to a solution or the creation and procurement of new products without understanding is not, as with all things, going to effect impactful change.
Cybersecurity and secure development practices will never progress until the skills are present to address the real issues –and the professionals with those skills are empowered to enact necessary changes.
Training and investment are needed –and required, by many regulatory and/or certification programs. Companies have been attesting to untruths either through ignorance or willful misrepresentation. While most would not voice it, most technical professionals already know this, and it keeps many of us awake at night.
Guidance and supporting tooling already exist. What is lacking is the impact of transparency, collaboration, and investment to align business initiatives with those secure practices. There is no silver bullet; it can only be achieved through digital transformation, changes in mindset, and the acknowledgement of the root problems. Anything less is just lip service.
Comments