President’s Letter

Welcome to summer, 2022! Each year at this time, we see at PSC two competing dynamics. First, there are events that are part of the annual cycle of budgets and contracts. Then, there are the new initiatives and priorities that come from Congress and the administration, either to shape the future or to respond to current conditions. This summer, we seem to have an abundance of work on both fronts.

As we do every year, PSC is closely tracking legislation, particularly the National Defense Authorization Act (NDAA) for funding priorities and policy changes that will affect national defense and security programs. The House Armed Services Committee’s version of the FY23 NDAA included a number of key provisions (note that the Senate marked up its version of the FY23 NDAA but at press time has yet to release details or language). You can read more in our regular Bill Tracker feature.

The more immediate concern for government contractors, though, is how the NDAA will help them address the cost growth from inflation and the tight labor market that they’re experiencing today. An inflation rate of 8.6% means increasing costs for labor, components and materials, and transportation have rapidly outpaced the assumptions built into existing contracts and into FY22 agency appropriations (which assumed roughly 2 percent for inflation).

PSC has urged the Administration to take action now to help companies address their higher workforce costs. One straightforward action would be to issue government-wide guidance to programs and contracting officers that, subject to available funds, encourages them to work with contractors to reimburse them for unexpected higher costs.

PSC members can check out the online Inflation Resource Center with both civilian and DoD-related inflation guidance and information, including the March 2022 GSA guidance and the May 2022 DoD memo. The Center also includes PSC actions and additional information and can be found on the PSC website and clicking on the “Resource Center” tab.

Beyond the NDAA and the impacts of inflation, PSC’s government relations team continues to track legislation related to workforce, cybersecurity, and annual appropriations. The PSC Bill Tracker (pg. 17) also includes the status of these and other key bills on the Hill.

In this issue you’ll also find articles on cyber, budgets, workforce, and more, including: • how industry meets the security challenges of federallyprocured software (pg. 6), • new procurement rules on labor law violations (pg. 9) • the benefits of clean audits (pg. 10), • the Coalition for Racial & Ethnic Equity in Development (CREED) Pledge (pg. 12), and • the value of intellectual property (pg. 27).

In June, PSC held our annual Acquisition Conference, with speakers engaged with our attendees both virtually and in-person on issues ranging from speed of contract award and governmentindustry collaboration to the impact of the Great Resignation and emerging cyber security rules.

We used this conference to roll out the latest PSC Business Forecast Scorecard, in which we rate 62 federal agencies and components, letting them know how well their posted forecasts fare against 15 criteria. Visit www.pscouncil.org and search Business Forecast Scorecard to see the results and the supporting comments from the government itself.

Finally, we look ahead to the remaining key PSC events this year: Defense in October, International Development in November, and the Vision Federal Forecast Conference in December. Each conference planning committee worked to create engaging agendas and facilitate valuable networking both in-person and virtual while following the proper COVID-19 safety precautions. I look forward to seeing you there.

As always, I welcome your input, your feedback, and your engagement in our efforts.

David J. Berteau, President and CEO

Navigating the Gap: Implementing Federal Software Security Requirements Now

by Victor Foulk, Director, Cybersecurity Leader, Emerging Technologies Practice, CGI

The time to begin integrating secure software development and acquisition requirements into the Federal portfolio is now. This is based on the most recent statement on “Enhancing The Security of Federally Procured Software,” issued by the Office of Management and Budget (OMB) on March 7, 2022. OMB’s statement is driven by the requirements of Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, and directs Federal agencies to begin adopting the National Institute of Standards and Technology (NIST) guidance on secure software development and software supply chain security immediately, tailoring it to the agency’s risk profile and mission.

To meet mission requirements, Federal agencies depend on the security and integrity of vendor-supplied third-party software. Hardening our software supply chains and integrating secure software development practices is truly a national security imperative, one that the current state of geopolitical unrest and critical infrastructure attacks underscores. This worsening threat landscape, coupled with large-scale breaches of trust in software integrity—like the SolarWinds Orion compromise discovered in 2020—have set the stage for arguably the most influential series of cybersecurity–related directives in US history.

The problem facing Federal acquisition professionals today is that many of the requirements themselves are still taking shape and some of the underlying technologies for compliance attestation are still maturing. Furthermore, the commensurate update recommendations to the Federal Acquisition Requirements are not due until May 2022. As such, agencies have to navigate the regulatory environment with a “more to follow” approach to software supply chain risk management. One that evolves efficiently over time. One that leverages collaborative engagement with their vendor base and establishes a roadmap for enhancing acquisition policies over time. One that strikes a balance between the vendor capabilities and the agency’s own technological maturity and risk tolerance.

We have never been closer to real change that demonstrably increases the baseline level of cybersecurity across Government, and these software security measures are a critical part. Waiting for clarity in future directives delays essential, incremental improvements in security and leaves current risks unaddressed. Following the proactive approach laid out in the rest of this article, leaning into the regulatory intent early, delivers improved security and awareness now and enables an easier transition over time with lower long-term cost.

Revisit Software Asset Management: Being good in cybersecurity requires being great at the fundamentals; software supply chain security is no different.

The intersection of cybersecurity and acquisition is asset management, and network defense depends on knowing what is on the network. Conduct an introspective assessment of existing acquisition policy, asset management practices, and inventory of assets. Having a comprehensive inventory is fundamental in building out a supply chain risk management program capable of measuring and understanding overall risk posture (e.g., vendor financial viability; foreign ownership, control and influence, etc.).

The software asset management assessment is also a great opportunity to do some focused application rationalization, stripping out redundancies and culling low-utilization applications. Reducing the number and diversity of applications in the environment not only reduces the asset management and regulatory compliance burden, it reduces the attack surface.

Using the software inventory, identify which applications meet the definition of critical software, and prioritize them based upon an assessment of risk a vulnerability in each would present to agency mission. In a strictly compliance-driven sense, only critical software is at play for the current generation of requirements. Agencies should, however, strongly consider the full continuum

Defining Critical Software

Per EO 14028, “critical software” is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes: • Is designed to run with elevated privileges; • Has direct or privileged access to networking or computing resources; • Is designed to control access to data or operational technology; • Performs a function critical to trust; or • Operates outside of normal trust boundaries with privileged access. NIST refined this definition for preliminary use in an October 2021 white paper, to help agencies scope the initial implementation of these requirements.

of software assets and apply the requirements on a graded scale to even non-critical software. Let Log4j be a lesson here.

The Apache Log4j vulnerability (dubbed Log4Shell) is just one recent example that highlights the importance of increasing our understanding of, and baseline level of security in, all of our software supply chains. Log4j is a ubiquitous piece of open source software that provides logging functionality in an immense number of products and services. Federal agencies and industry alike struggled to find and remediate the vulnerability due to its pervasiveness. The current requirements for secure software development and supply chain security could have mitigated much of this through the implementation of a software bill of materials (SBOM), discussed later.

Establish a familiarity with the technical details within the Secure Software Development Framework (SSDF), and look internally to benchmarks for “acceptable proof”, consistent with agency expectations and risk tolerance.

Before engaging the vendor base, and before establishing agency-specific acquisition policy, a consistent internal understanding of the baseline requirements is essential.

At a high level, the requirements are intended to ensure secure software development practices, as described in Section 4e, subsections (i), (iii), and (iv), of the EO. These are: (i) secure software development environments, including such actions as: continued pg. 8(A) using administratively separate build environments; (B) auditing trust relationships; (C) establishing multi-factor, risk-based authentication and conditional access across the enterprise; (D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software; (E) employing encryption for data; and (F) monitoring operations and alerts and responding to attempted and actual cyber incidents; (iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code; (iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release

The fast track to identifying what expectations of vendors are suitable for the agency, as well as tailoring expectations to agency mission and risk tolerance, is through benchmarking against the agency’s own network authorization documentation. The level of veracity with which an agency can document and attest to similar requirements in their environment will help to level-set expectations.

Admittedly, there is the potential that an agency’s own technological maturity in these areas is weak or still evolving, in which case retaining support from a trusted technical consultant is advisable. Such a consultant can provide the necessary technical expertise for near-term implementation of the requirements, training personnel as required, and helping the agency to define a viable and affordable path to maturity with the underlying security technologies. continued pg. 8

Engage the software providers within the agency ecosystem, and understand their actual level of technological maturity with respect to the secure software development requirements. Meet them where they are, with a plan to evolve.

The consolidated software asset inventory, prioritized by criticality and risk, should guide the engagement strategy with the vendor base. A structured data call or survey is the least-effort approach, but the results will fall short of truly informative. Ideally, the software acquisition team actively engages in a conversation with vendor subject matter experts to discuss, and seek an understanding of, the software development practices at play.

A vendor engagement should cover security practices from the EO, as discussed above, but also the vendor’s vulnerability disclosure program(s) and ability to generate effective SBOMs covering the whole of their supply chain, including open source software dependencies. This will serve to establish a high-level baseline understanding of the vendor’s conformance. It can also help shape the agency’s policy timeline, taking into account what the vendor ecosystem can provide now, and their plans of action and milestones to reach the next level of compliance over time. This information is key to building the agency’s roadmap for realistic policy evolution, driving feasible in partnership with the vendor base.

There is an obvious inconsistency in the guidance that agencies will have to grapple with. The OMB guidance issued on March 7 requires agencies to begin implementing the SSDF and related practices in software procurement immediately. However, it stops short of requiring agencies to invoke formal attestation requirements due to the ongoing development of standards for what constitutes suitable artifacts.

It is ill advised, however, to wait for those updates before engaging with, and requesting supporting data from, the vendor base. Agencies are on the hook for risk acceptance now. Even though NIST is hosting a public workshop on behalf of OMB to drive industry engagement on artifacts and attestation, achieving a consistent standard that can apply to all agencies is still likely far off. Thus, the forward leaning approach to implementation is a logical one, and cultivating a strong, communicative relationship with the vendor ecosystem is a proven best practice.

The Open Source Challenge

Much of the world’s software leverages open source codes and libraries. For open source materials that an agency uses directly, thoughtful consideration must be given to how the agency itself will attest to security. Many open source projects lack the resources to meet compliance objectives quickly. Ultimately, resources from the agency, a third-party contractor, or other source may be required to appropriately secure the open source supply chain.

Update agency contract requirements for software acquisition using a graded approach, applying the strongest attestation requirements feasible for the current maturity level.

A consolidated software asset inventory, prioritized by criticality and risk, coupled with the benchmarking achieved

NIST Guidance on Procurement

In February 2022, NIST provided guidance to acquisition and procurement officials regarding an appropriate conformance statement. Such statements should include: • Software producer’s name • A description of which product or products the statement refers to • A statement attesting that the software producer follows secure development practices • Name and title of who can provide the artifacts generated by the secure software development activities related to EO 14028 Sections 4e(i), 4e(iii), and 4e(iv).

through vendor engagement, will provide the agency valuable insight into the security of the software supply chain. Further, a clearer picture emerges of what expectations an agency’s vendor ecosystem can meet without triggering explosive costs.

At this stage, agency-specific policy changes can provide realistic improvements in software supply chain security now, balanced with the agency’s risk tolerance and the vendor ecosystem’s maturity. This includes a roadmap for adaptation over time to increase compliance and attestation requirements as the regulatory frameworks evolve. While work continues at the Federal level to define what artifacts are appropriate for secure software development attestation, agencies should begin with the basics, documented by the vendor via self-attestation. The bar, for now, should be set appropriately low, understanding that industry is adapting to these new requirements along with the Federal Government.

That minimum bar, however, should include a narrative vendor attestation that they do, or do not, meet the requirements as laid out in the NIST guidelines, and if not, when they expect to. Furthermore, agencies should require: • Details on the vendor’s vulnerability disclosure program. • Detailed expectations on vulnerability reporting. • SBOMs to the highest level of fidelity the vendor can provide under current technical maturity.

Each of these elements should be considered foundational, and are essential to improving an agency’s risk posture. Agencies can incorporate additional fidelity, with artifacts attesting to secure software development processes, into their acquisition requirements as the standards continue to evolve.

Next Steps on Our Journey

We, Government as well as the national industrial base, have a lot of hard work in front of us as we strive to elevate the baseline level of cybersecurity across all Federal sectors. Together, we can achieve the vision set forth in the most influential series of cybersecurity–related directives in US history.

For more discussion on this topic, or to discuss how to apply these principles toward evolving your software supply chain security program, feel free to reach out to me. 3