NIST's NICE: 3 ways to adapt the hiring framework for modern threats

The National Initiative for Cybersecurity Education's cybersecurity hiring framework may be a good place to start when putting together a solid security team. However, some changes are needed for NICE to equip teams with the knowledge, skills — and distinct roles — to enhance your software supply chain security (SSCS) strategy.

NICE is designed to be a comprehensive framework to address the cybersecurity workforce needs. It defines cybersecurity occupations; states the knowledge, skills, and abilities (KSAs) required for those occupations; and provides recommendations for training and certification programs that align with those KSAs.

The framework's limitations can diminish its usefulness for forging teams focused on application security (AppSec) and SSCS, however. Those limitations include a focus on traditional organizational security boundaries, inadequate coverage of distributed development environments, insufficient emphasis on dependency management, and gaps in addressing modern CI/CD security requirements, experts note.

Here's what you need to know about the NICE framework's limitations — and how to adapt it to build a modern team for the SSCS era.

Learn more with our Essential Guide: Software Supply Chain Security for Dummies

The NICE framework's origin explains its limitations

Jeff Williams, CTO and co-founder of Contrast Security, said the work roles defined in NICE are drawn from traditional projects that build a system without a massive and complex supply chain. And it was built using information collected from government employees and managers about what government roles actually address, said Carol Woody, technical manager of cybersecurity engineering in the CERT division at Carnegie Mellon University's Software Engineering Institute.

The supply chain includes many more roles that are not included.

Carol Woody

NICE needs to be modified to accommodate SSCS, said Sarah Jones, a cyberthreat intelligence research analyst at Critical Start, because today's software projects use so many third-party components and dependencies.

The NICE framework may need to place greater emphasis on knowledge areas related to software composition analysis [SCA], software bill of materials [SBOM] management, and dependency tracking. This is crucial for understanding and mitigating risks introduced by third-party software components and open-source dependencies.

Sarah Jones

Tim Freestone, chief strategy and marketing officer at Kiteworks, said that traditional cybersecurity roles often focus on securing organizational infrastructure, but SSCS demands expertise in identifying vulnerabilities in externally sourced software, tracking component provenance, and implementing safeguards against tampering.

As supply chains become more interconnected and complex, additional roles focused on auditing, monitoring, and responding to software supply chain threats would be essential, requiring NICE to expand its role definitions and competencies to encompass these areas.

Tim Freestone

There are three key areas for improvement of the NICE framework, experts stressed.

1. NICE needs a knowledge upgrade for the SSCS era

To accommodate software supply chain security, a number of NICE knowledge areas need to be enhanced, Freestone said, including these:

• Third-party risk management: Understanding how to assess and manage risks posed by vendors, suppliers, and contractors that provide software components
• SCA and SSCS: Knowing about tools and techniques for analyzing software dependencies and identifying vulnerabilities and malware in open-source and third-party code
• Secure software development lifecycle (SDLC) practices: Ensuring that security is integrated at every stage of software development, especially when sourcing from external developers or suppliers
• Provenance and integrity verification: Tracking the origin of software components and verifying their integrity to prevent the introduction of malicious code
• SBOMs: Ensuring transparency in the software supply chain with SBOMs that detail every component used in a software product

There are other considerations, said Critical Start’s Jones.

The framework may need to incorporate new knowledge areas covering supply chain-specific threats, such as compromised software updates, malicious code injection, and software supply chain attacks. Analysts would need to understand these emerging threats and how to detect and respond to them.

Sarah Jones

Expanding coverage of secure coding practices, secure software architecture, and integration of security throughout the SDLC would help organizations build more secure software and mitigate risks introduced by vulnerable code, Jones said.

Guy Rosenthal, vice president for product at DoControl, said knowledge of the intricacies of modern software supply chains — with their complex web of open-source components, APIs, and cloud services — is also crucial.

This should also include a deep understanding of data sharing and access levels within partner systems. It's not just about what data is shared, but also how it's shared, who has access to it, and what controls are in place to protect it.

Guy Rosenthal

2. Expanding the NICE skill set is key

NICE skills also need to be enhanced for software supply chain security. Updated technical skills should include the ability to work with SBOM tools, perform container scanning, and build pipeline security tools, while management skills should include the ability to perform vendor security assessments, implement open-source governance, automate security policy, and respond to supply chain incidents.

Tomas Gustavsson, chief public key infrastructure officer at Keyfactor, said business risk assessment skills and knowledge in managing dependency management are needed skills. "Even things like programming language–specific risks and tooling come into play,” he said.

Jones recommended the following skills be added:

• Proficiency in SCA and SSCS tools and techniques
• The ability to interpret and utilize SBOM data for risk assessment and mitigation
• An understanding of supply chain attack vectors and mitigation strategies
• Familiarity with secure software development practices and DevSecOps methodologies

DoControl's Rosenthal said there's also a growing need for skills in automated security testing and continuous monitoring of the entire software lifecycle. “Professionals also need to be adept at analyzing and managing the levels of access granted to partner systems, ensuring the principle of least privilege is applied even in complex, interconnected environments,” he said.

Rosenthal said new competency areas should include:

• Supply chain resilience: The ability to design systems that can withstand and recover from supply chain attacks
• Transparency and traceability: The ability to maintain clear visibility into all components and dependencies within a software system
• Partner ecosystem management: The understanding of how to evaluate, monitor, and manage the collective risk posed by all partners and suppliers in the ecosystem

3. Added roles are needed for ownership

Some additional work roles might be needed to make NICE more relevant to SSCS, said Ian Amit, founder and CEO of Gomboc.AI. The skill set of security engineers, for example, “would encompass secure coding, application security, and even software forensics and reverse engineering,” Amit said.

Jones suggested some other potential roles:

• SSCS analyst: Responsible for monitoring, analyzing, and responding to threats and vulnerabilities within the software supply chain
• SBOM manager: Oversees the creation, maintenance, and distribution of SBOMs to enable transparency and risk management
• Secure software architect: Designs secure software architecture and integrates security throughout the SDLC

Another key role needed, said Rosenthal, is third-party risk analyst, who would specialize in vetting and monitoring the security posture of vendors and partners. “This role should include expertise in exposed data intelligence — understanding what information your suppliers might be inadvertently leaking about your organization or other vendors. This kind of intelligence is crucial for a comprehensive risk assessment,” said Rosenthal.

Sean Wright, head of application security at Featurespace, said most of the roles in the design and development area cover most of what is required for SSCS. "However, I would like to see the mention of a dedicated security resource in terms of software development, ideally an AppSec engineer," he said.

They would understand security requirements, as well as the impact of those requirements from a development perspective and where it makes sense to include them or not. They would also help in the research and investigation of where controls can result in extra scrutiny of third-party software being used within the organization.

Sean Wright

Joshua Knox, an evangelist at ReversingLabs, said that a lot of companies have an actual AppSec role, but NICE doesn't use that term. NICE has roles in secure software development, secure system development, and software security assessment, but it completely missed the mark on AppSec, he said.

They're spreading that load across a couple of roles. That's dangerous, because when you are only partially responsible for something, it's easy to fall through the cracks. There isn't a role for 'the buck stops here for application security.'

Josh Knox

Is NICE ready for prime time?

Ultimately, adapting NICE for SSCS isn't just about adding new elements, Rosenthal said; it's about integrating this perspective throughout the entire framework. “Every cybersecurity role today needs to have some understanding of supply chain risks and how to mitigate them, including the nuances of data sharing and access management in partner ecosystems,” Rosenthal said.

Tom Marsland, vice president of technology at Cloud Range, said that despite its limitations, NICE needs to be more broadly adopted by the industry.

The NICE framework is a great tool to communicate the requirements of job roles. NICE should be included in job descriptions, hiring profiles, and a platform that assists people to meet the needs of their employers. It’s useful at many levels — and I’m disappointed in the industry at the slow rate of adoption. Training providers, employers, educators, and end users all have a stake in the NICE framework.

Tom Marsland

Not everyone agrees, however. Jori VanAntwerp, founder and CEO of EmberOT, said that the logic behind NICE comes from a false narrative around the cybersecurity skills gap. The gap is being caused by unreasonable expectations by hiring authorities, overspecialization, education focused on theory and methodology, and compartmentalization and complexity of action, VanAntwerp said.

NICE absolutely intends to address the skills gap and software supply chain issues, but it does so by exacerbating all those issues.

Jori VanAntwerp

He argued that NICE adds even more specialization, allows academia to further disconnect from real-world practice, and introduces even more complexity to workflows and oversight. While defining categories seems helpful, we will either need to water down the definitions of those categories or constantly create new ones as technology and business evolve. "It looks great on paper but can potentially cause much more harm in actual practice," he said.

Implementing a straightforward policy utilizing Secure by Design, transparent reference architectures, and software catalogs will heavily mitigate the same risks NICE targets — which is what the community has been preaching for over two decades. And companies are just starting to adopt these methodologies, VanAntwerp said.

Purposeful action is the only thing that will turn the tide.

Jori VanAntwerp