Software Supply Chain Security: Now is the Time to Act

It’s time to make evaluating and mitigating software supply chain security attacks top of mind as government agencies, corporations, industry analysts, and security firms try to chart a course forward for supply chain security after the SolarWinds hack.

Security Challenges 

Here are some software supply chain security challenges you should keep at top of mind now and in the future:

  • Software updates are a well-known best practice but can also introduce risk. However, with SolarWinds, customers received software that was signed but compromised. In following this best practice, they did just what the attacker wanted by installing the compromised software on your systems. 
  • Software behavior monitoring — another best practice — met its match in the stealthy and patient attackers who created so much damage inside SolarWinds before their discovery.
  • Source code reviews are inefficient, as the SolarWinds hack shows. Some reports point out that attackers had control of the SolarWinds build environment, making it possible for them to insert malicious code without knowing the SolarWinds Orion development team. 

When traditional security practices and solutions such as these fail on such a grand scale, it becomes time to reevaluate how software supply chain security works in organizations of all types. 

The SolarWinds hack exposes many of the significant drawbacks of today’s supply chains to the light of new and changing cybersecurity realities. 

Changing supply chain security means galvanizing your teams and counterpart teams in all the commercial partners and vendors that touch your supply chain to become true partners with open communication lines, collaboration, and knowledge sharing.

While large corporations may vet software vendors’ security through questionnaires or independent assessments, more still needs to be done to reduce risks across the software supply chain. Work beyond that initial questionnaire and subsequent onboarding means focusing on automated vulnerability scans and other methods to shore up your process for bringing in software components or applications.

Security, development, and IT teams must collaborate to ensure sufficient security checks and remediation of issues at each software supply chain stage. Those compliance processes must apply to software from all sources, whether open source, commercial vendors, or internal developers. 

Best Practices

There isn’t a single security solution that can secure your software supply chain from attacks. The gravity of the SolarWinds attack is an invitation for you and your software supply chain partners to collaborate and reassess the security, governance, communications, and collaboration needs across your supply chain. Here are some best practices you are bound to see and experience in the post-SolarWinds world:

  • Improve relationships and collaboration
  • Improve governance of software onboarding 
  • Harden your build environment
  • Require an SBOM for all partners and vendors
  • Implement Defense in Depth
  • Apply “Zero Trust” to software supply chain security 
  • Create a “kill chain” for your software supply chain

Read our White Paper

Today, software supply chain security requires continuous awareness, collaboration, and new strategies. We no longer live in a time to sit still when it comes to software supply chain security.

Software Supply Chain Security, Best Practices for Cloud-Native Application Development

The SBOM + Threat Intelligence are the Future of Software Supply Chain Security

As organizations open up the software bill of materials (SBOM) to their security teams, there is a future of the SBOM as source data for threat intelligence is becoming abundantly clear. Applying intelligence to SBOM data is a natural step in a world where DevOps and DevSecOps teams use a range of tools and technologies such as AIOps and analytics to gain actionable intelligence from their backend data.

Here’s a look at how the SBOM and threat intelligence spells the future of software supply chain security:

SBOMs Today

We’re reaching a critical point with the role of the SBOM in today’s enterprise. After the SolarWinds hack, it’s incumbent for government agencies and businesses to open up the SBOM to their security teams. Options to make this work include:

  • Offer training to your internal teams about SBOM basics with an accompanying briefing about what your organization expects to get 
  • Give your security team the tools and support to make the SBOM the first “gate” before third-party software code and components enter your software supply chain.
  • Put in the tools and processes to generate SBOMs as part of your DevSecOps toolchain and processes

Threat Intelligence Today

Threat intelligence, also known as cyber threat intelligence (CTI), is organized, analyzed, and refined information about current or potential attacks according to Whatis.com. An entire industry has arisen around threat intelligence that includes platforms, open source, and fee-based data feeds.

Choosing a threat intelligence platform means knowing your goals and requirements for data collection, and how the platform presents its threat analysis and reports to your security team. If you already have a threat intelligence platform in place that your security team manages, it’s time to work with your team and, if necessary, the vendor, to explore potential integration options for pulling in SBOM data into your threat intelligence reporting. There’s not a single hard and fast answer here (at least not yet) but the platform application programming interface (API) is the logical starting point.

The SBOM and Threat Intelligence in the Future

The SBOM is an under-realized threat intelligence option. For example, let’s say that you want to integrate an open source software (OSS) project into an enterprise software project you have underway for an important customer. The project is highly functional and shows excellent potential to serve as a key feature in your solution. Then the OSS project suffers a security incident. There are also vulnerabilities appearing in the same OSS project weekly.

A commercial or open source vulnerability scanner can only tell you whether some piece of that OSS project is vulnerable. It doesn’t give you any sort of status or analysis that alerts to the project’s history in the “vulnerability of the week club.”

While that OSS project with the vulnerability a week remains appealing, that there’s an OSS project with vulnerabilities is lost on the vulnerability scanner. You have a commercial option that fills most of the requirements but has only suffered two vulnerabilities over its entire lifetime. That’s probably the safer bet. We need to reach a point where we couple SBOMs with intelligence to help raise the role and importance of SBOM as a key security data source.

Even if you have the staffing budget to hire 100 people and their whole role in life is to determine the threat status of your open source dependencies, they still need a technology solution that enables them to narrow down what they examine as third-party software enters your pipelines. 

Final Thoughts

As businesses and governments continue to tackle the rise of software supply chain attacks, they and the vendors that serve them need to look at coupling SBOMs with some form of intelligence. Threat intelligence is a logical bet. It’s time for threat intelligence platform vendors and their customers to work collaboratively on solutions to add SBOMs to their feeds by default.

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.

It All Started With a Fish Tank

It all started with a fish tank…  You don’t hear that often, but for Anchore employees Touré Dunnon and Amy Oxley, this hobby was just the thing to start their Anchorenaut friendship.  

Touré’s 250 gallon saltwater aquarium is the real deal. It has an impressive mechanical and biological filtration system that holds 400 gallons total (2500 lbs). Touré grows seaweed and keeps the water extra clean for his nine fish from Fiji and the Caribbean.  

This advanced level of aquatic life didn’t happen overnight.  Touré learned his love of fish through his Dad, who started him out with a 10 gallon saltwater tank when he was 13.  After college, Touré got back into aquariums with his two daughters who help manage the water changes, clean the tank, and feed the fish.  Since he was interested in becoming a marine biologist as a kid, Touré is hoping his daughters will be inspired to pursue that path when they get older.

Outside of his fish tank fatherhood, Touré is a Senior Software Engineer on the Anchore platform team, primarily working on policy engine with a key focus on keeping active containers within compliance.  

Meanwhile in Texas, Amy’s three-year-old daughter Fynn’s obsession with the Finding Nemo movie piqued her interest in starting a fish tank hobby. It wasn’t until seeing Toure’s aquarium during an Anchore All-Hands virtual meeting that she was inspired to commit.  Amy’s 40 gallon freshwater tank has 11 fish, complete with schools of tetra, catfish, and shrimp.  

While still aspiring to make her tank more automated (and eventually upgrade to a saltwater tank as “saltwater fish are way cooler”), Amy and Fynn love to count the fish and learn their names. 

Amy is the Senior Manager of the IT and Information Security team, filling her days with managing Anchore’s internal systems for both ease of use and compliance while maintaining and managing the company’s security initiatives.

Toure and Amy’s friendship has continued to grow – with Touré being a fountain (dare we say, an aquarium) of knowledge for Amy as she has embarked on her fish tank journey, being her go-to person for questions on everything from water changes to the ideal plants and fish to purchase next.  They even connected on their hobby of woodworking, and strategize on how to build stands and support systems for their fish tanks.  

In a distributed company during an unprecedented time, Touré and Amy’s friendship is an example of the unconventional ways people can make a connection through something as simple as a video conference background. You can keep up with Touré and Amy (and their aquatic hobbies) on LinkedIn.

Plugging an SBOM into your DevSecOps Process

The software bill of materials (SBOM) is gaining renewed attention and notoriety post-SolarWinds. More companies and government agencies seek deeper transparency into the software components entering their software supply chain.

While there are critics out there that believe that the SBOM is a misguided concept for DevSecOps, the continuing evolution of DevSecOps, much less the automation it brings to development teams today, now makes SBOMs a foundational aspect of the DevSecOps process.

SBOMs: The New Gate to the DevSecOps Pipeline

It’s time to treat the software BOM as a barrier to entry for software components entering your DevSecOps, not just your container repository. Requiring an SBOM for all software entering your pipeline has become a common-sense best practice in this day and age. You have three options for obtaining SBOMs:

  • Gain full cooperation from the software vendor, despite whether they’re a partner of your organization, with the SBOM as part of their delivery 
  • Implement software composition analysis tools that require particular expertise 
  • Implement a container vulnerability scanning tool that enables you to generate SBOMs for the containers entering your pipeline 

Moving software bill of materials generation to the left is just another step in moving security left. Depending on your particular business processes, compliance requirements, and pipeline gateway requirements, it’s essential to add a documented or automated process (or better yet, a combination of the two) that ensures that each software component has an accompanying SBOM before it enters your development environment As an example, let’s say your developers are taking advantage of an open source software (OSS) component in a cloud-native application built for one of your most important customers. OSS projects don’t have the resources or staff to generate an SBOM. It’s not something they do. Nothing stops your teams, however, from creating an OSS onboarding process and putting in the right tool to generate the SBOM for the OSS themselves before the software even hits your development environment and software repositories.

SBOM, Say What?

There are some details from industry surveys and various industry mutterings that project that less than half of the companies out there are creating SBOMs for their software. It’s not about the SBOM being a misguided concept for DevSecOps either. Currently, organizations just do not build SBOM creation into their DevSecOps processes. You control the gates at all phases of your DevSecOps toolchain. It’s up to you to put in the tools and processes upfront (“to the left”) to ensure that all software from your in-house teams, contractors, partners, vendors, and OSS enter your DevSecOps toolchain, much less your enterprise software supply chain.

Accountability for the SBOM is a New Priority

Accountability for SBOMs seems to get lost in the rush to deliver new software. It’s time for that to change.

Beyond putting in the tools and processes to capture an SBOM at contract time or have your team generate an SBOM for OSS, here are some examples of how you can build in SBOM accountability inside your organization:

  • Include SBOM as a requirement for contractual deliverables from your vendors and partners, making it part of new software development, updates, and patches they deliver as part of a project.
  • Establish the SBOM as a method for cross-functional team collaboration early in the project lifecycle because your contracts, finance, development, and cybersecurity teams all benefit from a well-formed SBOM to help them accomplish critical project-related tasks.
  • Deputize a developer or development team to “own” or shepherd OSS components through your DevSecOps toolchain, giving them the responsibility of generating an SBOM for each component.
  • Elevate the role of your cybersecurity team in the SBOM discussion by mandating that the SBOM serves as the basis for vulnerability scans.

Final Thoughts

Your development, security, and operations teams have probably already put a lot of work into creating the culture, processes, and frameworks to enable your organization to leverage DevSecOps. Factoring in the role of the SBOM into your DevSecOps processes is yet another iteration of your DevSecOps processes. 

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

The Software Bill of Materials (SBOM) through an Open Source Lens

This blog post has been archived and replaced by the supporting pillar page that can be found here:

https://anchore.com/wp-admin/post.php?post=987473384&action=edit

The blog post is meant to remain “public” so that it will continue to show on the /blog feed. This will help discoverability for people browsing the blog and potentially help SEO. If it is clicked on it will automatically redirect to the pillar page.

Bringing Gratitude into the Workplace: Meet Emily Long

 

Emily Long (she/her) joined Anchore one week after the pandemic shut down the U.S. in March 2020, she was employee number 25. In her Chief People Officer role, Emily led the build out of the G&A (General and Administrative – self titled ‘Great and Awesome’) functions made up of Finance/Accounting, IT, Information Security, Recruiting, HR, Legal/Compliance, L&D (Learning and Development), and DEI (Diversity, Equity and Inclusion). Though she’d be the first to tell you, the best part was hiring “the incredibly talented team that really does the work.”

Through her value system and leadership approach focused on empowerment, team dynamics, and trust, Emily’s impact has extended to her recent move into the Chief Operating Officer role where the Customer Success organization has joined forces with the G&A team.

In this Humans of Anchore profile, we (virtually) sat with Emily to hear about her journey over the past year, what the organization has accomplished, and what inspires her:

“I feel a deep sense of gratitude that I’ve been part of Anchore during the growth we have experienced over the last year. That gratitude is attached to what makes our growth special – that it’s always been about us accomplishing this together, as a collective company and team. Everyone here believes in what we’re doing, and every single person that works here is part of that success. Being able to partner with a team that is low ego, and high in humility and kindness, makes those wins as a company that much more fulfilling.

Everything that we accomplish at Anchore – whether that be product features, financials, training materials, or metrics – has people behind it. Teams of people collaborating together to solve problems. If we don’t understand the person that is developing code or supporting our customers, we aren’t telling the whole story. We can’t fully understand the quantitative outputs we get without deeply understanding the qualitative inputs that create it. Notably, the people behind the data.

What makes us different is not putting more or less focus on the technical or non-technical side of our business, rather putting an equal focus on both. We believe that everything is connected and we can get increased technical innovation through empowerment of our team members. And not just by saying it is important – but doing something about it. I can honestly say I’ve never worked somewhere that has focused on this more – a true example of this was hiring me originally as Chief People Officer at employee number 25.

We have worked hard to ensure the way we operate gives every team member a sense of belonging – that we take the time to understand how each unique person works, exploring their ideas, and hearing their concerns. This community of empowerment exists in a crew of almost 70 Anchorenauts. We have this infrastructure built to enable us to continue this as we scale because we have invested the time, energy, and resources through internal education, individual ownership, and structural support. We believe this is key to our success, for every employee.

Anyone who has worked closely with me hears me say all the time that I genuinely believe that people are fundamentally good. Most of the time when I’ve seen people become defensive, shut down, or act out in some way at work it has been a result of insecurity or a lack of trust that they’ve learned through past experiences – and I’ve been there before. There is honestly nothing better and more inspiring than watching someone shed away those walls they’ve built by experiencing what trust really looks like and truly stepping into their power. I get to witness this at Anchore all of the time – and each time I’m filled with a deep sense of pride and gratitude.

My ultimate goal is to have everyone at every level here at Anchore believe in, and have a path to achieve, that limitless potential that lives in each of us. Working somewhere with people that believe in each other, want to be part of a greater good, and are willing to hand the mic to someone that needs it more than they do… now there’s something really beautiful about that.”

We’re debuting our Anchorenaut logo

As we continue our culture-first series, this Friday we’re debuting our Anchorenaut logo (pronouns they/them).

By definition, an Anchorenaut is someone that embodies our company values and what being an Anchore employee encompasses: kindness, openness and ownership. We have a strong-knit team here, even though we’re dispersed geographically across the globe. This character serves as a symbol of how together, we’re real people uniting every day to advance software security.

Does this resonate with you? See our open roles here: https://lnkd.in/edDC7bf

 

At Anchore we’re passionate about our products and our industry

At Anchore we’re passionate about our products and our industry, but we’re equally committed to building a company with amazing people, incredible career opportunities, and an ability to make a difference. We’re thrilled to start sharing more about who we are and what matters to us through the launch of our culture-first series.

On Fridays, you can expect to learn more about who Anchore is. We’ll give you a closer look at:

The Humans of Anchore: The people (including pets and little ones!) who help shape our company.

Be Yourself. With Us: A highlight reel of new jobs and a glimpse into the people you could be working with at Anchore.

Mission: Impact: This is where we show you our programs and initiatives and how they enable us to live out our core values every day.

So, come learn more about why we’re excited to work here. And maybe a little about how you can make that a reality for you, too, someday. Come be yourself. With us.

https://hubs.li/H0G636d0

Curious what it’s like in a startup?

Curious what it’s like in a startup? As we continue our culture-first series, today we’re diving into the jobs and people at Anchore. All startups are different, at Anchore we focus on ensuring all employees, from individual contributors to the exec team, are given the opportunity to challenge themselves and explore new skillsets.

We talked to Support Engineer Tyran H. in the UK about his time on the team.

“Anchore is my first encounter working at an actual startup and is an amazing place to experience the real deal. Plus, I also have the opportunity to learn and develop technologies at the forefront of the tech world.”

Not only is Tyran part of our growing customer success team, but he was also Anchore’s first UK-based employee.

“As the first overseas hire, being welcomed as part of the family to help Anchore grow from the ground up has made settling in easy. It feels more like working on a passion-project with a group of friends than ACTUAL work, which is a massive bonus!”

Want to join Tyran and our team? Check out our latest job listings here.

From Olympic Athlete to DevOps Engineer

When Alfredo Deza came to work here at Anchore it was early in the startup phase, he was employee #16. His path to Anchore began after a storied upbringing in his native country of Peru, where Alfredo competed as a high jump athlete in the Athens 2004 Summer Olympics. He then shifted his determination and perseverance to study how to become a developer. 

“My goal is to translate the stamina and work ethics from athletics to my work as an engineer. Having discipline, not letting my guard down, and doing things the right way has enabled me to propel forward in my career,” said Deza.

After building a strong skill set in software coding and engineering, he pursued a career as a software engineer and still fuels his passion for computer programming in his free time. 

Alfredo has co-authored a book “Python for DevOps” and is currently writing another book on machine learning. He teaches courses on Python and CI/CD, and recently was an expert panelist at GitHub Universe 2020

When he’s not mentoring the next generation of developers and engineers, Alfredo spends time with his wife and three children. He consciously tries to expose his kids to new experiences and let them guide their own interests, in fact, his oldest recently taught himself to play the piano.

“When you carve your path to success with effort, you can apply the principles of ownership and see great results. If you do what you say and live with objectives, amazing things will happen.”