What’s Critical Software? NIST Responds

Part of President Biden’s May 12, 2021 Cybersecurity Executive Order (EO) is for the National Institute of Standards and Technology (NIST) to define critical software as part of the goal for strengthening the security of government purchased software.

NIST recently delivered on that aim and the definition of critical software has the potential to influence government IT as a whole. Plus the companies that sell IT services and software into the federal government could feel the impact in unexpected ways. Let’s take a closer look…

The Meaning of Critical Software

Software runs the United States federal government. It powers the processing of government benefits. Government researchers on the front lines of the pandemic rely on cloud computing power. America’s warfighters rely on software to run logistics, process real-time intelligence, and for R&D. Here’s the official NIST definition of critical software:

EO-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 privilege or manage 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.

This definition strikes at the heart of software in government and DoD infrastructure. Critical software manages access to mission-critical systems that play key roles in government programs including support of the warfighter, intelligence community (IC), and other government programs that support the health and vitality of United States citizens and the economy.

The preliminary list of software categories includes software at every level of the technology stack:

  • Identity, credential, and access management (ICAM)
  • Operating systems, hypervisors, container environments
  • Web browsers
  • Endpoint security
  • Network control
  • Network protection
  • Network monitoring and configuration
  • Operational monitoring and analysis
  • Remote scanning
  • Remote access and configuration management
  • Backup/recovery and remote storage

NTIA defines “Critical to trust,” as “categories of software used for security functions such as network control, endpoint security, and network protection.”

Critical Software: Definition + Dependencies

As required by the order, NIST’s definition of critical software focuses heavily on software that has elevated privileges or controls access to an organization’s computing resources along with related direct software dependencies. Here’s the definition from NIST:

“Direct software dependencies,” means, for a given component or product, “other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for operation of, the software instance in question. This is not a systems definition of dependencies and does not include the interfaces and services of what are otherwise independent products.”

The direct software dependencies mentioned are where the definition of critical software gets interesting. Agency and DoD software development bring together the work of multiple vendors and open source projects. Government programs are going to need a level of software transparency now that maybe wasn’t in their previous request for proposals (RFPs). 

It’s the NIST definition of dependencies that gives new meaning to critical software. Dependencies mean software libraries, packages, and modules that are necessary for software operations. NTIA has quite a task deciding how deep an SBOM detail should go into when capturing software composition.

Industry Feedback  & SBOM Visibility

Industry feedback has been sent to the NTIA asking for flexibility, especially on how deep an SBOM should be required to go in describing its transitive dependencies, according to NextGov

Granted there’s still an industry need for a definitive software bill of materials (SBOM) standard, the comments focus on SBOM limitations due to software versioning and identification issues. They also cite the importance of context when it comes to vulnerability information. Lastly, they mention the level of effort and resources required to prepare SBOMs.

While the SBOM isn’t a new thing in software development, yet it’s not in as wide of use as you’d expect. President Biden’s cybersecurity executive order has the potential to finally give the SBOM some teeth. 

SBOM generation to be effective requires automation and just as importantly, a definitive industry standard. Automated generation of SBOMs is a natural step in a DevOps or DevSecOps toolchain. Platform-centric toolchains can make this a new feature or API-based integration. Traditional DevOps/DevSecOps toolchains are open for integration as well.

Government acquisitions and procurement officials have yet to enter the critical software discussion. The definition that NTIA is championing is going to have an impact on how request for proposals (RFPs), statement of works (SOWs), and even the other transaction authority (OTA) procurement vehicles. Post-cybersecurity EO RFPs must now account for:

Such additional considerations may expand the scope of RFPs. Expect a learning curve from agency contracting officers and respondents alike during the first round of IT proposals.

Do you want to generate SBOMs on the OSS in your development projects? Download Syft, our open source CLI tool for generating a Software Bill of Materials (SBOM) from container images and filesystems.

Settling into a Culture of Kindness

Blake Hearn (he/him) joined Anchore in February 2020 as a DevSecOps Engineer on the Customer Success team, marking the start of both Blake’s professional career and entry into DevSecOps.  In this Humans of Anchore profile, we sat down with Blake to talk about learning new skill sets, a culture of kindness, and lessons from leadership.   

Settling into a Culture of KindnessFrom his start at Anchore, Blake has been immersed in a team of kind and supportive people offering him the mentorship, resources, and encouragement needed to be successful.  

“The whole team really helped me learn at a fast rate. They created training materials and testing environments for me to learn, checked in with me frequently, and even recommended some certifications which played a huge role in building a foundational knowledge of DevSecOps.  A year and a half ago I didn’t know anything about Docker, Jenkins or Kubernetes and now I’m using them every day.” 

Blake’s support system reaches far beyond his direct team, extending all the way to the executives and co-founders of the company. 

“I’ve had a really great experience with my managers and the leadership team. Being able to reach out to the CEO or CTO is amazing.  Dan Nurmi (CTO/Co-Founder) has open office hours each week where I can bring my technical questions and feel comfortable doing so. Everyone at Anchore is really collaborative. I can ask anyone a question and they are more than willing to help.” 

In his role, Blake spends most of his day working on the Platform One team at the Department of Defense (DoD) partnering with engineers from companies across the industry to help deliver software solutions faster and more securely across the DoD.

“It’s been a really good opportunity for me to learn from both my Anchore team and my Platform One team. My role requires a lot of custom Helm templating and testing updates on various Kubernetes clusters.  We are putting our minds together to come up with solutions and do groundbreaking work.”

Looking ahead, Blake is eager to continue his learning journey. “I’m excited to continue learning from others and get into new skill sets. Recently, I’ve learned a little bit about the operational side of Machine Learning (ML) and how ML could be used in cybersecurity. Next, I would like to get into penetration testing to help improve the security posture of products and services. I think that would provide a huge benefit to our customers – especially with the supply chain attacks we’ve seen recently in the news.”

In summarizing his time at Anchore, Blake is grateful for the support system he has found: “I didn’t think companies like Anchore existed – where the company’s culture is so kind, everyone is really smart, works well together, and you have direct access to leadership.  No other company I’ve seen compares to Anchore.” 

Interested in turning your dreams into reality? Check out our careers page for our open roles anchore.com/careers

 

Developing Passionate and Supportive Leaders

Anchore’s management program is founded on passionate people leaders who are kind, open, and invest in their team’s success.  Finding passionate leaders means opening the door to opportunities for all employees. We empower Anchorenauts to apply for management roles and participate in a cross-functional interview process.     

A few months into Dan Luhring’s (he/him) time at Anchore, a management role opened up in the Engineering organization.  When the Director of Engineering asked if anyone on the team was interested in pursuing the role, Dan immediately raised his hand. 

Developing Passionate and Supportive Leaders“When I interviewed for the manager position with the leadership team, I was glad that I was going through a formal process because it made me realize that Anchore understands how vitally important great managers are to the success of the company.”

Upon joining the Anchore management team, all leaders go through a robust training program where they learn more about different communication and working styles, coaching conversations, and the guiding principle of Anchore’s management philosophy: building trusting relationships.

“I love our manager training series.  I thought the role-playing exercises were really thoughtfully done and have been missing from manager training I’ve done in the past. Between the training sessions, ongoing employee programs, and overall partnership, I feel really supported by our People Operations team in my role.” 

Anchore’s continuous performance model enables our managers to set a strong foundation of trust and clear communication from day one.  Although Dan had already been working with his team before becoming a manager, the Stay Interviews gave Dan even more insight into his new direct reports. 

“I got a ton of value out of the Stay Interviews with my direct reports. It’s really useful to know what motivates people, how they like to receive recognition and feedback, and what their long-term career goals are.  It made me more aware of their professional interests outside of their day-to-day responsibilities. Because I know the motivators of my direct reports, I can assign special projects based on individual interest, even if it’s not something they do in their core role.”  

Reflecting on his opportunity to join the management team, Dan is excited to be part of making Anchore a great place to work and continuing to lead his team based on trust.    

“There are things that Anchore gets right that I find to be really unique. We are thoughtful about who we promote into the management team.  We have great support and autonomy with helpful programs and tools to facilitate trusting relationships, really caring about the people who report to us and wanting to help them achieve their career goals.”

Interested in becoming a team leader like Dan? View Anchore’s current openings here.

Anchore Enterprise 3.1 Streamlines End-to-End Container Security

Container security is a team sport.  Development teams need to avoid delays by finding and fixing security issues early in development, while DevOps teams must check compliance before they deploy. Security teams must continuously monitor for new vulnerabilities that impact production environments. Collaboration among these teams is required for efficient and effective security processes. Anchore Enterprise 3.1 adds new capabilities to expand automation of container security across these stages from development to production. This will advance the team’s collective goals and ultimately, speed to market.

Runtime Image Monitoring for Continuous Security

Anchore Enterprise 3.1 makes it easy to monitor your running containers and quickly evaluate images for security and compliance risks. Security teams can now watch entire Kubernetes clusters, gain visibility into overall risk in production, and be alerted of new vulnerabilities. Our new UI makes it easy to layer in our extensive policy language and start using Anchore’s admission controller to enforce security across your critical Kubernetes clusters. Watch a video of Runtime Image Monitoring in action.

New AnchoreCTL Client Automates Pipeline Scanning 

Designed for use with Anchore Enterprise, AnchoreCTL is a new command-line client that makes it easier to automate container scanning within the CI/CD pipeline. With AnchoreCTL, customers can distribute scanning tasks across their CI/CD platforms and pipelines, increasing throughput and reducing time-to-analyze for Anchore Enterprise. 

AnchoreCTL incorporates the capabilities of Anchore open source tools Syft (SBOM generator) and Grype (vulnerability scanner) while adding support for the reporting and compliance APIs in Anchore Enterprise. AnchoreCTL is also fully supported under the Anchore Enterprise support agreement and SLAs. Those who are ready to move from open source to Anchore Enterprise will benefit from an easy migration path from Syft and Grype to AnchoreCTL.  AnchoreCTL can be installed through a binary, container, or a growing number of package managers. Watch a video of AnchoreCTL here.

Simplified STIG Compliance for US Federal Agencies

The Federal Edition of Anchore Enterprise 3.1 greatly simplifies the process of DISA Security Technical Information Guide (STIG) checks for containers running in a Kubernetes cluster. With Anchore’s new cloud-native tool  STIG tool REM, federal agencies can fully automate what was once a time-consuming manual process. The results of STIG checks are aggregated and correlated within Anchore Enterprise, providing security teams with a single pane of glass to report on STIG compliance issues along with vulnerabilities and other compliance checks. Watch a video of STIG Compliance Checks.

Kubernetes Adoption by the Numbers

Our recent 2021 Anchore Supply Chain Security Survey sheds some light on Kubernetes adoption and growth in the enterprise as it pertains to running container workloads. 

For this blog post, container platforms based on Kubernetes run containerized applications, whether during development and testing, staging, or production. These platforms run in house, through a hosting provider, or from a cloud provider or another vendor.

K8s Stands Alone

Perhaps the most interesting Kubernetes stat in the survey is that 71% of respondents are using a “standalone” version of Kubernetes that’s not part of a platform as a service (PaaS) rather it’s run on-premise or even on cloud infrastructure as a service (IaaS).

The second most used container platform is Amazon Amazon Elastic Container Service (ECS) with 56%. 

53% of the respondents are using Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Services, and Red Hat OpenShift for their container management and orchestration.

We’re at an interesting point for Kubernetes adoption as these numbers show. While there’s a well-known Kubernetes skills gap, organizations are still relying on their own teams, most likely augmented with outside contractors to deploy and operate Kubernetes. While the major cloud service providers (CSPs) are the logical platform for outsourcing Kubernetes infrastructure and the related backend management tasks the numbers point to the fact they are still gaining mindshare in the Kubernetes market.

Container Platforms Used

K8s and Large Workloads

Cloud-native software development is now delivering at an enterprise-scale on major development projects that include 1000+ containers. Here’s the spread of Kubernetes adoption in use on these business and mission-critical projects:

  • Standalone Kubernetes (7%)
  • Amazon ECS (7%)
  • Amazon EKS (7%)
  • Azure Kubernetes Service (7%)
  • SUSE-Rancher Labs (6%)

This tight spread of K8s platforms paints an interesting picture of the scale where these large enterprise projects play. Standalone Kubernetes, Amazon ECS, Amazon EKS, and Azure AKS are all at a tie. The continued presence of standalone Kubernetes is a testimony to early adopters and the growing reliance on open source software in large enterprises.

It’ll be interesting to revisit this question next year after large enterprises have gone through more than a year of COVID-19 driven cloud migrations which could give CSP offerings a decided advantage in the new world of work.

Looking Forward

Kubernetes is still experiencing exponential growth. The Kubernetes responses in our survey speak to a future that’s being written as we speak. 

The complexities around deploying and operating Kubernetes still remain and aren’t going to disappear anytime soon. That means that the open source projects and CSPs offering Kubernetes solutions are going to have to focus more on simplicity and usability in future releases. Along with that comes a renewed commitment for outreach, documentation, and training for their Kubernetes offerings.

Do you want more insights into container and software supply chain security? Download the Anchore 2021 Software Supply Chain Security Report!

A Custom Approach to Software Security Solutions

We’re hiring a Product Marketing Manager! In this week’s Be Yourself, With Us, SVP of Marketing Kim Weins shares the exciting opportunities within the role. 

Product marketing at a startup like Anchore provides a lot of room to leave your stamp, since our product is evolving quickly based on problems our customers need to solve,” said Kim. 

Anchore’s customer base ranges from large enterprises like NVIDIA and eBay to government agencies like the U.S. Space Force and the U.S. Air Force. Being nimble to create custom solutions is critical for our expanding software security products.

“On top of that, we’re in a rapidly growing industry with a solution at the nexus of cloud, containers and security. There’s immense potential for what Anchore can provide for customers and the Product Marketing Manager is going to have a huge impact on how these solutions are communicated to the rest of the industry,” she continued.

Are you passionate about the future of software security and curious about the next innovation that will help secure data and prevent cyberattacks? Then consider joining our marketing team. Visit this link to apply.

Secure the Software Supply Chain: 5 Insights from the 2021 Anchore Software Supply Chain Security Report

The challenge of building and maintaining a secure software supply chain continues to vex enterprise IT leaders. We recently surveyed IT, security, and development leaders in the Anchore 2021 Software Supply Chain Security Report to get some insights into these challenges they and their teams face daily.

Here’s a preview of our survey results:

Highlights from the Survey

Container usage is on the rise as these highlights from the survey show:

  • 65% of the respondents replied they are at intermediate or advanced levels of container maturity
  • 84% plan to increase container use and 29% will increase container use significantly. Respondents use containers for both internal applications and software products they sell.
  • 38% of advanced container users see containerized apps as a higher supply chain risk versus 16% of beginner container users

1. Open Source is the Top Container Security Challenge 

Developers incorporate a significant amount of open source software (OSS) in the containerized applications they build. As a result, 23% of respondents rank securing OSS containers as the number one challenge. In a tie for second place (19%) is understanding the security of code that an organization writes themselves and understanding the full software bill-of-materials (SBOM).  SBOMs are a critical part of President Biden’s Executive Order because they are the foundation for many security and compliance practices.

Open Source is the Top Container Security Challenge

2. Software Supply Chain Attacks Cut Deep

With over 18,000 organizations affected just by the SolarWinds attack, a software supply chain attack has affected a significant majority (64%) of respondents within the last twelve months. Over a third of the respondents report that the impact of a software supply chain on their organizations was moderate or significant.

Software Supply Chain Attacks Cut Deep

3. Containers and Software Supply Chain Risk

We saw an interesting statistic in the survey with 38% of advanced container users seeing containerized apps as a higher supply chain risk versus just 16% of beginner container users. 

These stats paint an intriguing picture of container adoption that’s entering middle age. When you look at the rise of Docker containers since 2013 leading into the current generation of cloud-native development. Long-time container users recognize the security risks of containers inside the supply chain. A new generation of developers adopting containers is starting on their own learning journey.

Software Supply Chain Attacks Cut Deep

4. OSS, SBOM, and Container Security Rank as Challenges

Open source software (OSS) ranks as a top container security challenge according to 23% of the survey respondents. Meanwhile, the software bill of materials (SBOM) is a top challenge for 19% of the respondents.

Another interesting insight from the survey is that some enterprises still underestimate OSS as 26% of components and code where some industry benchmarks such as the Synopsys 2020 Open Source Security and Risk Analysis Report point to OSS comprising 70% or more of components and code in today’s applications.

Bar chart showing comparison of top container security challenges.

5. The Truth about False Positives

We hear a lot about container vulnerability scanning challenges and the damage that false positives can do to a security team’s credibility. Survey respondents laid out their top three challenges:

  • Identifying vulnerabilities (86%) 
  • Receiving too many false positives (77%)
  • Getting developers to remediate issues (77%)

On average, survey respondents estimate that 44% of vulnerabilities they find are false positives.

 

Do you want more insights to help build and maintain a secure software supply chain? Download the Anchore 2021 Software Supply Chain Security Report!

Carving a Career Path That Fits

Startups come with many opportunities – the ability to partner directly with leadership, to move quickly with decision making, and to work on a variety of projects across the organization. At Anchore, we have intentionally designed our internal programs to provide employees with equitable opportunities for mentorship and career growth. 

Through our continuous performance model, we built opportunity into the foundation of our company culture. We do this by ensuring every employee (regardless of background, tenure, or level) feels empowered to raise their hand with an idea, question, or express interest in a new project. Anchorenauts have ample opportunity to expand their skills as they work towards short-term and long-term career goals.  

Instead of focusing solely on linear career paths, we give employees the opportunity to pursue other roles or career aspirations.  

Andre Neufville (he/him) joined Anchore in November 2019 on the Customer Success team, with a focus on designing solutions that integrate container security best practices into customer DevSecOps workflows.  “My role was to interface with customers and prospects, help them understand how to operate Anchore in containerized environments and integrate container scanning in their development workflows, but there was also an added sales aspect that I hadn’t done before.”

Client service wasn’t always the focus for Andre.  Prior to Anchore, he worked on systems administration and network security. 

“Early on I developed an interest in understanding the components of a secure enterprise network and used that knowledge to design better security around systems and network architectures. At the same time, cloud adoption grew and companies began developing modernization strategies for enterprise infrastructure. I transitioned to the role of a Cloud Security Architect in which I was able to apply my previous experience to advise customers on how to secure their cloud infrastructure and workloads.

When Anchore’s InfoSecurity and IT team was expanding, Andre expressed interest in the role during a continuous performance discussion and was supported by his manager to pursue the opportunity.  The IT Security Engineer role proved to be the perfect opportunity to combine his past experiences and current interests (as Andre is also in the process of getting his Masters degree in Cybersecurity Technology).  

“In the past, I partnered with and advised customers on architecting solutions without the ownership of seeing it through.  The InfoSec role has given me an opportunity to apply the same principles internally, but rather than just advising how it should be implemented, I get to follow through and look for areas of improvement. The whole end-to-end approach really intrigued me and my general affinity towards security that I’ve had in all my roles. I’m grateful for the opportunity to be a part of our internal IT Security initiatives and look forward to learning and growing in the role.

Supporting employees to pursue alternative career opportunities within our organization is an integral part of Anchore’s culture – truly embodying our core values of kindness, openness, ownership.  For more on our open roles, check out our careers page here.

3 Tips for getting Stakeholder Buy-in for DevSecOps

Gaining stakeholder buy-in for DevSecOps comes with some upfront work. You don’t want to present to your department’s leadership, much less your C-Suite, to talk about DevSecOps unless you have an accurate picture of where your development teams are currently and where they need to go in the future.

Here are three tips for preparing to get stakeholder buy-in for DevSecOps:

1. Analyze your Development Process Maturity

Whether DevSecOps is just the next step in your DevOps journey or you’re making your initial foray into DevSecOps straight from a waterfall SDLC, a critical step in the first phase is to analyze the maturity of your software development process. Your analysis should include:

  • Document any current state processes
  • Gather any reporting data about your current development processes
  • Interview key developers about what’s working and not currently working in your development processes
  • Interview key security team members about what’s working well and what’s not working in their processes and procedures that support your applications in development and production

Before presenting this information to your stakeholders, distill it down into the key points in a format that’ll resonate with your stakeholders. For example, if you work in a data-driven organization, then let the numbers tell your story. Non-technical stakeholders may also need a quick DevOps to DevSecOps education that hones in on how DevSecOps benefits their piece of the business. 

2. Define DevSecOps for your Organization

Software vendor marketing and the OSS community each put their spin on the definition of DevSecOps. Therefore, as part of your outreach, it’s important to define DevSecOps for your organization, including:

  • What DevSecOps means to your organization
  • The expected outcomes after moving to DevSecOps
  • The tools and processes your organization is putting into place to ensure employee success

Spare your teams from any misunderstandings and document your DevSecOps definition. Post that definition in a place that’s accessible to all your team members and stakeholders. It’s not about creating a project charter for your DevOps to DevSecOps transformation, but defining your true north.

3. Plan for a DevSecOps Culture

Like DevOps, you can’t buy DevSecOps. Your managers and key technology team members need to work together to foster DevSecOps cultural philosophies that take your DevOps foundation to DevSecOps transformation.

Culture can be a squishy word to some stakeholders. It’s important to couch DevSecOps culture in business terms with an eye for how it benefits the organization. A simple way to do this is to create a DevSecOps roadmap with milestones for each major transformation point, including:

Continuous Feedback and Interaction

Cross-functional DevSecOps teams may collaborate remotely, which can create challenges with continuous feedback. It’s not about a manager delivering feedback on the DevSecOps team performance. Instead, it’s about enabling teams to collaborate more effectively. ChatOps tools such as Slack, Microsoft Teams, and MatterMost can now replace email for DevSecOps teams. As technology such as artificial intelligence (AI) improves, you can expect to see more automation through chatbots.

Container-Based Architectures

The shift to cloud-native applications is driving the adoption of container-based delivery models.  DevSecOps plays a critical role in the move to container-based architectures, which can be a cultural change in and unto itself for DevOps teams. A proper and robust implementation of containers changes developer and operations cultures because it changes the development model of how architects design solutions, programmers create code, and how operations teams maintain production applications.

Team Autonomy

Like DevOps, DevSecOps is no place for micromanagers at any level of your organization. A standard part of DevSecOps culture is enabling your teams to choose their own tools and create their processes based on the way they work. DevSecOps also promotes distributed decision models to support greater innovation and delivery velocity.

Automation

DevSecOps extensively embeds automation for security checks and remediation workflows directly into DevOps processes and toolchains. An automation strategy that extends to security is a sign of a healthy DevSecOps culture. 

DevSecOps Training for Developers

Another step to security becoming part of everyone’s job is to provide security training for your developers. Training could take the form of in-house developer training in casual formats such as Lunch and Learns or more formal training classes conducted by your organization’s training department. Another option is to send your developers to a third-party training provider to get the requisite security training. Depending on your security ambitions (and budget), there is always the option to send your DevOps team members to get a vendor certification such as the DevSecOps Foundation certification from the DevOps Institute the Certified DevSecOps Professional (CDP) from practical-devsecops.com.

Final Thought

Preparing your case to advance your DevOps journey with data, a current state picture of your development processes, and a plan to transform your development team culture enables you to meet your stakeholders with the facts and strategy they require to make a decision to grant budget and staffing to the effort.

Behind the Scenes of Startup Team Strategies

Building products in an emerging tech space requires a highly collaborative and creative Engineering team. We sat down with Chief Architect & Director of Engineering Zach Hill (he/him) to understand more about creating an environment of psychological safety and operating with a growth mindset.

“At a high level, psychological safety is about fostering an environment where people feel comfortable saying ‘I don’t know’ – because it’s safe to do so and we’ll figure it out together. We’re a fast-paced startup with high-tech products in a fairly emerging industry, and that means much of what we are working on is developing as we go and we are all learning and growing together.”

Anchore’s values of kindness, openness, and ownership play an integral role in the Engineering team culture. 

“You can see it in our Slack channels. You can see it in the way people on the team interact with one another and with their managers. We have a highly collaborative team that’s open to asking for help and being mentors to one another.  It’s an exciting time to be an Engineer at Anchore.” 

If you are interested in joining Zach’s team and working at a company that values kindness, ownership and openness, we’re hiring across our Engineering organization.