Category: Blog

From Olympic Athlete to DevOps Engineer

Posted on by Brandie Gerrish

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.”

The White House Executive Order Is a Call to Action for Software Supply Chain Security 

Posted on by Kim Weins

Last week, President Biden released an executive order (EO) mandating a sweeping review of the federal government’s supply chains. In response to high-profile software supply chain hacks most notably the recent SolarWinds hack, the order went beyond physical supply chains to address the security of software supply chains as well.

The federal government depends on supply chains to provide material support for everything from personal protective equipment (PPE) for frontline workers to furniture for State Department facilities worldwide to complex IT systems across the DoD and civilian government agencies. Fortune 1000 corporation supply chains serve a similar role to companies and often stretch to suppliers around the world. The fact that this order makes direct mention of software supply chains is an indicator of the role software plays in our daily lives.

Treat this Executive Order as a Call to Action

The sheer complexity of software supply chain security means it’s time for commercial and public sector DevSecOps teams to learn from one another. The executive order makes the following request for a review of information technology software, data, and services that the government purchases with their 53.36 billion dollar IT budget.

“The Secretary of Commerce and the Secretary of Homeland Security, in consultation with the heads of appropriate agencies, shall submit a report on supply chains for critical sectors and subsectors of the information and communications technology (ICT) industrial base (as determined by the Secretary of Commerce and the Secretary of Homeland Security), including the industrial base for the development of ICT software, data, and associated services.”

While this EO directly hits systems integrators (SIs) and other businesses that do work for the Department of Defense and civilian government agencies, the EO also applies to manufacturers in the semiconductor and other industrial bases that serve as foundations to the economic prosperity and security of the United States. 

Key Considerations of  Software Supply Chain Security 

Every software supply chain security initiative in the aftermath of SolarWinds needs to encompass two major aspects.  First, it must cover the security of the workloads or applications being constructed,and second, it must cover the security of the DevSecOps toolchain” (eg the tools, platforms and infrastructure) that is used to build the software.  While cybersecurity teams have long focused on securing production infrastructure, the SolarWinds breach has called attention to the need to better secure the systems used by developers to build software applications.

Secure the Workload

Securing the software workload is a common practice that starts with setting policies to govern the use of source code from public repositories such as GitHub and ensuring software in your private repositories is properly vetted and secured. Policies should also extend to employees and contractors housing your source code in their personal source code repository accounts. Another crucial security step is to secure your source code “secrets” — application programming interface (API) keys, OAuth tokens, passwords, and more — that can provide authorized access to your application. Secrets that are left in source code are available to all repository contributors, whether cloned, copied, or distributed.  If an attacker gains access to your source code repository, your secrets can be co-opted for their malicious attack. 

Beyond the usual source code security concerns, there is also the prospect of intellectual property (IP) theft if an attacker accesses your source code repository. High-profile software source code leaks have struck both the consumer and defense industries for various reasons.

Because modern, cloud-native applications are often composed of a myriad of containers from open source and software suppliers, securing containers should take the form of a zero-trust strategy. Because containers may enter the software development process at many different points, organizations must embed continuous compliance and security checks at each stage of the development lifecycle. You can use open source or commercial tools to scan containers for vulnerabilities and generate a software bill of materials (SBOM) to ensure the software components match the vendor contract or documentation.

Secure the Toolchain

The next key security move is securing the entire software development toolchain  — the entire set of tools and platforms that are used to build your workloads.-. You should focus on the security of your DevSecOps toolchains including your continuous integration/continuous development (CI/CD) platforms. Such systems can become a target for man in the middle (MiTM) and other attacks. Security measures include:

  • Protecting distributed applications
  • Securing wired and wireless access points
  • Mandating VPN access for remote workers
  • Creating policies and controls to protect against unapproved shadow DevOps tools

Ensuring the security of your test/QA environments should be an integral part of your QA infrastructure build-out. It helps to have QA staff with a grounding in secure architecture to make this happen. If nobody on your QA team has that skill, look for ways to assign a member of your security or operations team to support the build-out of your QA infrastructure.

Security of production infrastructure is the area where most security teams already spend significant effort, including implementing threat detection, runtime application self-protection (RASP), and related measures. Expanding the security focus to include the systems used in earlier stages of the software development process provides additional layers of protection and improves the overall security of the software supply chain. 

Take Action

Now is the time to reevaluate your software supply chain security. Here are some immediate steps to take:

  • Audit your source code repositories especially access management and secrets security.
  • Examine the feasibility of a zero-trust security strategy for your source code and work with your DevSecOps teams to create a roadmap/plan on how your organization can implement such a strategy to protect your source code.
  • Implement tools to enable your DevSecOps team to generate an SBOM for open source and commercial software components you are onboarding to your toolchain.
  • Audit your DevOps toolchain security and architecture if you haven’t already done so with an eye on protecting distributed applications, securing wired and wireless access points, mandating VPN access for remote workers, plus creating policies and controls to protect against Shadow DevOps tools. 
  • Audit the security of your Test/QA infrastructure, focusing on the architecture and then the same security elements as the rest of your DevOps toolchain security audit.
  • Reinforce your application production security with threat detection, RASP, and other tools to shield your production applications from attackers.

Request a demo today to learn how Anchore Enterprise can help secure your DevOps toolchains and software supply chains!

Charting your DevSecOps Stakeholder Spectrum

Posted on by Will Kelly

The adoption of DevSecOps touches more than just your technology and security stakeholders within your organization. There’s a full spectrum of DevSecOps stakeholders spanning technology, security, and even your business units.

The full DevSecOps Stakeholder spectrum includes:

Technology Stakeholders

The obvious stakeholders to feel some positive effects and challenges of moving to DevSecOps are your technology leaders, such as your chief technology officer (CTO), chief information officer (CIO), and engineering VP.

Their motivations typically include developer productivity. Security teams also can become more productive because of a DevSecOps transformation through automation and adjustments to job roles and processes.

DevSecOps is a mighty robust preventative measure to keep these stakeholders and their teams from getting caught up in expensive security remediation efforts that draw attention away from their regular duties.

An essential role for the technology stakeholder is to be the internal champion for DevSecOps or be the one to empower somebody on their senior staff to be that champion. The DevSecOps champion at the stakeholder level needs prompting to represent your organization’s current and future needs at high-level strategy and budget discussions.

Security Stakeholders

If your organization has a chief information security officer (CISO) or chief security officer (CSO), they are a significant element in your DevSecOps stakeholder spectrum.

Duties of a security stakeholder focus on managing and maintaining the security posture of build environments, software supply chain, and end products. The CISO, often with the CIO, may represent the organization about security matters such as a recent attack on or breach within your organization.

Business Stakeholders

You can’t dismiss the role of business stakeholders in DevSecOps either. These are the business unit leaders that may feel the most impact from DevSecOps. The good news is that such effects are positive if the units work with the technology team to put the right processes, frameworks, and content to tell the story of how DevSecOps benefits your organization. Here are some typical DevSecOps stakeholders on the business or back-office side of your organization:

Sales 

Your sales leaders and representatives gain many benefits from DevSecOps that you can’t gloss over. Positioning the benefits of DevSecOps with sales leaders and their teams who can benefit from it can help them land prospective customers.

Suppose your company has clients in the public sector or the financial services and healthcare industries. In that case, DevSecOps can help your applications achieve compliance more quickly since your organization has shifted security and compliance left.

DevSecOps is becoming an emerging requirement on DoD and civilian government agency procurement vehicles. If your business works with these entities, then you want to arm your sales stakeholders with the correct talking points about your company’s DevSecOps efforts.

Marketing

DevOps culture transformation shouldn’t just be about your development, operations, and security teams. Marketing stakeholders such as your chief marketing officer (CMO), VP of marketing, or marketing director need visibility into your DevSecOps efforts just like other parts of your organization.

Your marketing stakeholders need a share in the collective responsibility to ensure that the software your organization delivers meets expectations and is a market fit for the business customer you’re pursuing.

Marketing teams supporting the launch of new products and services need constant visibility into the DevSecOps project progress. Likewise, developers earn a view of marketing activities. The days of surprises in marketing collateral should be no more in a DevOps culture. DevOps also offers sales organizations a conduit to communicate customer feedback and requirements into the development cycle, so incremental releases can include customer-requested features.

Automation is a priority in DevSecOps. It’s up to you to educate your marketing team on how automation changes how your organization delivers software internally and externally. 

Finance

The chief financial officer (CFO) role is seen as a more strategic role considering the pandemic’s effects on business. Similar positions in federal government agencies also see a similar change as agencies juggle budgets to support their mission, constituents, and employees.

Even the finance department has a potential role in your DevSecOps process. While an accountant may not be billing their time to your DevOps projects, there’s work for them with facets of software license management, plus your cloud spending.

Cloud economics and cloud cost optimization are integral elements of digital transformation projects these days, just like DevOps. Don’t forget to add the finance team to meetings when building out reporting requirements for the DevOps toolchain, cloud migration, and cloud management solutions that’ll power your software development efforts.

Legal

Your organization’s chief legal officer (CLO) or outside counsel is another link in the DevSecOps stakeholder spectrum.  Legal counsel is helpful as software licensing becomes more complex due to open source and commercial software components come together in product development. There are also potential legal issues as you establish software supply chains with licensing and contracts where having a legal stakeholder comes in handy.

When you make legal counsel part of your DevSecOps stakeholder spectrum, you can count on the right software licensing questions and concerns before making a costly intellectual property (IP) or licensing mistake.

Final Thoughts

DevSecOps not only transform how you develop and secure software, but it also transforms your business or agency business units as well. Like it or not, DevSecOps makes software development truly a cross-functional effort. It’s up to you to bring the DevSecOps stakeholders together to ensure the success of your DevSecOps initiatives.

Your DevSecOps Toolchain: 6 Steps to Integrate Security Into DevOps

Posted on by Will Kelly

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=987473366&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.

Creating a DevOps to DevSecOps Framework for your Organization

Posted on by Will Kelly

A DevOps to DevSecOps transformation works best with a structured framework acting as governance. When you approach such a transformation, putting structure around it allows you and your teams to stop, ask questions, and iterate on potential changes to your existing DevOps processes.

Here’s a simple framework to help ensure an orderly DevOps to DevSecOps transformation:

1. Outreach and Education

A move from DevOps to DevSecOps is far from strictly a technological affair. Such a transformation will significantly impact your developers, sysadmins, project management, and stakeholders.  DevOps to DevSecOps transformation touches other business units when it enables them to deliver on projects to their customers at a higher velocity and more securely. There may also be changes in how your other business groups interact with your development teams for new feature requirements and related matters.

Outreach and education with developers can take a couple of forms. First, you want to seek developer participation in your transformation. It’s time to create internal advocates and champions for DevSecOps. That’s a little easier to do if your organization is already a DevOps shop. However, you’re going to need to extend your outreach efforts to your security team as well. When you build advocates and champions for DevOps to DevSecOps, your development teams become self-policing towards fear, uncertainty, and doubt amongst your developers who aren’t ready about making a move to DevSecOps. You can only do so much to change developer attitudes if you’re not working with them daily and understand their pain points.

Sysadmin outreach plays out much the same way as developer outreach. Build allies. Work with them through any potential changes to their job duties, especially for bringing security checks and scans into their daily work.

There are also outreach and education considerations that may take you out of your IT department to educate the business about DevSecOps. A move to DevSecOps is going to affect the executive management team over the DevOps teams. You want to set expectations about the benefits of DevSecOps and automation. 

Exiting the outreach and education phase means you’ve met with your developers, sysadmins, stakeholders, and management. You’ve also delivered DevSecOps training, whether in-house or through an outside provider, to help upskill your developers and sysadmins and teach them about the benefits of DevSecOps. During this phase, security training may also extend to secure coding and vendor training on the DevSecOps security tools you plan to implement.

This phase is also a good time to survey the market and seek potential vendors to help you integrate security. Visit their websites. Watch their online demos. Ask thoughtful questions about their products and services in such online DevSecOps communities such as DevOps Chat and The DevOps Institute. You should also seek solutions and insights from the open source community that may help you secure your DevSecOps delivery cycle.

If you work inside a large corporation or government agency, establishing a DevSecOps Center of Excellence (CoE) brings together the DevSecOps expertise from across your organization. It can channel them into helping solve some technology and cultural challenges your organization might face in your move to DevSecOps. 

2. Implement Security across your Toolchains

Just like you’re giving your DevOps teams a choice in deciding upon their DevOps tools, the same should apply to the DevSecOps security. Whether you have teams choose open source or vendor-based DevSecOps solutions, the only caveat is that your organization’s requirements are met.

This phase may overlap with the Education and Outreach phase depending on your organization’s schedule and related factors.

While you’re building out your DevOps toolchains with additional security tools and features, it’s also a good time to audit the security of your DevSecOps toolchain itself. Remote DevOps teams and the growing prevalence of cloud-based DevOps tools comprising today’s toolchains making for attractive targets. Attackers are targeting toolchains with man-in-the-middle (MitM) attacks to compromise the development environment.
Exiting this phase means your new security measures are in place and generating your required reports. Depending on your organization’s maturity and situation, it may also mean improving the security of your access controls and endpoints against future attacks.

3. Pilot Project

There’s no better way to confirm that the tools and processes you’re putting in place for your DevOps teams to move to DevOps are working than a real-life pilot project. Pick a small internal project with an owner who’s keen to move to DevSecOps. Put your best people on the project and use it as a learning opportunity for your developers and sysadmins. It’s also an opportunity to educate your business stakeholders about the benefits and virtues of DevSecOps because you can show business value.

Exiting the pilot project stage can happen once the project is live and you’ve captured the lessons learned and rolled them back into your DevSecOps processes.

4. Full DevSecOps

Once you hit full DevSecOps, your job still isn’t done. When your organization hits this point, it’s time to take a continuous learning and collaborative approach to development and operations to speed up and secure your software delivery.

Don’t forget an ongoing feedback mechanism once your DevOps teams move into full-on DevSecOps. You want to take in developer and sysadmin feedback to apply lessons learned through a DevSecOps Center of Excellence (CoE) or another forum where your organization can intake the information without filtering through management, bureaucracy, or corporate politics.

DevSecOps isn’t meant to be a static state of being. You need to put your lessons learned into practice. You also need to offer ongoing training to your teams moving to DevSecOps.

Final Thoughts

Taking a systematic approach — such as an adoption framework — moving from DevOps to DevSecOps provides your teams and stakeholders with enough structure to transition their projects and job roles into this new way of developing software securely. This approach allows you to discuss your progress with your DevOps teams and their stakeholders at mutually agreed times during your transformation. 

5 Ways a DevOps to DevSecOps Transformation Changes Teams for the Better

Posted on by Will Kelly

Whether your organization is moving from DevOps to DevSecOps or making the initial step from a traditional waterfall software development life cycle (SDLC) to DevSecOps, you need to account for how DevSecOps is going to change your teams.

Here are five changes your teams can expect when your organization moves to DevSecOps:

1. Security becomes part of everyone’s job.

Perhaps the most significant change that comes to DevOps teams when they take the next step in their DevOps journey to move to a DevSecOps model is that security becomes part of everyone’s job.

It starts with incorporating security from day one of the project, whether it’s a new cloud application your organization is launching or an update to an existing application. When you take this first step, security is the “Department of No” or “It’s us versus them” when seeking approvals or collaborating on resolving security issues.

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 DevSecOps vendor certification such as the DevSecOps Foundation certification from the DevOps Institute or the Certified DevSecOps Professional (CDP) from practical-devsecops.com.

Finally, it’s also critical to document secure coding standards for developer onboarding and their later reference to ensure security becomes a part of the developer’s job.

2. Priorities may change

Trust between your security and DevOps teams will not improve overnight. The key to building trust between these teams — traditionally at odds in some organizational environments — is about prioritizing results. Both teams need to set priorities that are best for the project delivery and the overall business. For example, some software bugs that the team may encounter during development may not be enough to halt a product release. The development and security teams

3. Instills a Fail Fast culture

Unfortunately, in some corporate cultures, even the thought of failure can paralyze software development projects or keep the teams working in an endless loop redoing work to avoid releasing a product.

When “Fail Fast” becomes part of team culture, developers identify bugs as they build. That’s a big contrast to the days when developers or QA would work on bugs during the last few days (or hours!) before product launch. DevSecOps culture enables developers to take the time to fix issues in development versus spending hours or days fixing the issue once your application is in production.

Elements of a “Fail Fast” culture include:

  • Failure becomes a learning experience for the team rather than a career-ending incident.
  • Teams document lessons learned from the failure and put in the tools and processes to ensure the failure doesn’t happen again.
  • Testing. QA and remediation are recurring aspects of the DevSecOps lifecycle enabling developers to find bugs and issues during the development lifecycle before your application hits production.
  • Ask for help becomes a rule rather than an exception, with team members not worrying about losing face to their fellow team members and management.

“Fail Fast” cultures aren’t born overnight. Creating such a culture requires management support, accompanied by building trust across the teams who work together to deliver software. Most of all, management needs to lead by example and show their teams that failure is a learning opportunity, so take the extra time to put actions behind words if you’re a manager or stakeholder.

4. Increases Transparency

DevSecOps is no place for job security through obscurity. The DevSecOps culture warrants transparency between developers, security, and operations teams during their work. Increasing transparency requires the work of everybody to open collaboration between groups.

Here are some examples of how DevSecOps increases transparency:

  • Security teams enter the DevOps lifecycle, ensuring developers, security, and operations teams see everything through the same lens while working together.
  • Teams begin to use the “same language” since they are now working together during the development lifecycle.
  • As engagement between development, security, and operations teams grows, it can finally be possible for these groups to see they are all aligned to a single goal and start dropping the “us versus them” attitude that can sometimes affect how these teams collaborate with each other.

Another element of transparency that you should monitor on your teams is engagement. Be prepared to work with teams and staff who might have been working in silos either deliberately or through no fault of their own.

5. Treat Metrics as your Missing DevOps Team Member

Tools across the DevSecOps toolchain are chock full of data for teams and their stakeholders to track. DevSecOps culture enables teams to tell their data-driven story to internal stakeholders such as executives and project sponsors.

Some metrics to consider capturing during your delivery lifecycle include:

  • Reduced Total Security Tickets Opened
  • Discovery of Preproduction Vulnerabilities
  • Reduced Time-to-Remediate
  • Reducing Failed Security Tests
  • Percentage of Security Audits Passed

When choosing DevSecOps tools, make sure that analytics and reporting tools are prominent in your requirements.  Also, be prepared to iterate on metrics and reporting as you and your stakeholders learn more about your organization’s reporting capabilities and needs.

DevSecOps and Other Business Units

Also, keep in mind that many of the changes that DevSecOps demands of development and operations teams also trickle out to the business units that sit around the periphery of software development projects. For example, business stakeholders will have to factor more security requirements into their project requirements. Your executives have the opportunity to tap into more backend data from your DevSecOps toolchain and view actionable data through dashboards that your teams can set up and configure.

DevSecOps also provides your compliance auditors with new options for tapping into security and application data that would have required extra efforts in the days of waterfall software development.

Final thoughts: Building the Better DevSecOps Team

Setting up a DevSecOps team for success isn’t about just throwing some security tools into your existing DevOps toolchain and considering it done. It’s about cultural transformation and transparency. The first employees to feel that change will be in your development, operations, and security groups. These are also the team members you need to buy in on your DevSecOps vision.

Anchore Enterprise 3.0 introduces New Features to Secure the Software Supply Chain

Posted on by Neil Levine

Hopefully, heralding the start of what is a happier new year for everyone, today we are pleased to announce the availability of Anchore Enterprise 3.0. Over the past 18 months since our last major release, much has happened in the world of software security (and beyond!). From the software supply chain becoming a national security issue to the major developer platforms prioritizing DevSecOps in their roadmaps, the practice of hardening the entire software-delivery lifecycle is now front and center of all organizations. 

We’ve taken a hard look at the fundamental challenges of taking a true “shift left” approach to cloud-native security. Finding vulnerabilities or flagging issues in software is not difficult. Every piece of software has something that could be of concern. The critical challenge is doing it to reduce developer friction by avoiding noise, providing relevant context, and clear remediation steps. Let’s drill into the major features of the 3.0 release, which help our customers achieve these goals. Check out our launch video:

Bringing the Kubernetes Context to Container Alerts 

Anchore Enterprise has integrated with Kubernetes for a while, blocking images being deployed that fail to meet security standards. With 3.0, we’ve taken that a step further and now connect into the operational Kubernetes environment to catalog the running instances with our Kubernetes Inventory feature. We can flag any containers which have active vulnerabilities or are now failing policy or compliance checks that have run or are running Kubernetes. By marking the relevant image digest in your registry as being currently run in production and its being a security concern, developers can more easily prioritize their response to alerts.

A Distributed Model for CI/CD Scanning

Many security tools in the container space wait for an image to be published to a registry by the CI/CD system before scanning it, adding performance overhead and placing the burden of scanning on a central security platform.  To distribute the processing effort and improve pipeline speed by reducing network traffic, we’ve completely refactored how we integrate with GitLab, GitHub, and other popular CI/CD tools. Our new Go-based Pipeline Scanner tool creates the Software Bill of Materials (SBOM) from the container image locally in the CI/CD platform itself and sends the results to the central Anchore system. Anchore then sends back the policy result to pass or fail the CI job. This new deployment model improves the operational cost of running the Anchore system while also simplifying the security scan’s operational overhead in the pipeline.

Helping Security Teams help Developers

You have security information from the pipeline scan and situational awareness from the Kubernetes inventory. What should a developer do next? Our Remediation Action Plans are a brand new addition to our user interface, allowing security teams to generate clear instructions for developers on how to resolve security alerts. Pre-populated suggestions created by Anchore Enterprise can be combined with contextual information and then sent out to popular messaging or ticketing systems.  This powerful combination can help developers, who are probably not security experts, understand the options available to them, resolve issues faster, and allow additional research to be passed along by the security team. 

Reducing False Positives 

False positives are the bane of all security teams, wasting time and effort on wild goose chases. On the container input side, we added a “Hints” capability in 2.4 which allowed developers to explicitly describe software content to help improve vulnerability matching and reduce false positives. In 3.0, we’ve added a new False Positive Management feature so security teams can modify artifact metadata after it has been extracted by Anchore’s system. This allows for gaps or inaccuracies in the data generated during a scan to be fixed thereby ensuring better fidelity with associated fields in the vulnerability database. This is particularly useful for particular language artifacts such as Java which either have inaccurate metadata or don’t have any data at all.

Finally, DevSecOps teams deal with false positives are often dealt with by allowlisting specific packages. This provides a quick and instant way to unblock a pipeline. However, allowlists tend to linger, making what is often intended to be a temporary reprieve to an image a permanent exception. This in itself can become a security concern as fixes are not followed up. With our new Allowlist Expiration feature, security teams can ensure that exceptions to deployments can be time-limited on a customizable value.

Looking Forward

Anchore Enterprise 3.0 is going to continue to receive regular updates throughout the year. We plan to continue adding more runtime features and deeper integrations with the CI/CD platforms while improving the fidelity of security information. As ever, we look forward to hearing from customers and do sign up for our upcoming Anchore 3.0 webinar entitled How to Secure Containers Across The SDLC. 

DevSecOps and Defense in Depth for Software Supply Chain Security

Posted on by Will Kelly

One challenge that needs addressing in the software supply chain security fight is the balance between agility and redundancy in enterprise security strategies. There’s no better example of that than the recommendations about moving to DevSecOps and implementing Defense in Depth to improve your software supply chain security.

DevSecOps and Software Supply Chain Security

The shift left movement that DevSecOps offers can be vital to securing software build environments. DevSecOps is the next step beyond DevOps, a cultural change that brings security into DevOps rapid release cycles.

DevSecOps is built for agility and velocity. It relies on a range of open source tools to automate the software build cycle. It’s also not uncommon for organizations to put their own spin on DevOps and DevSecOps to meet their security and compliance requirements. There’s plenty of room for enterprises adopting DevSecOps to “build to suit,” which can make it challenging to maintain DevSecOps standards across vendors serving a software supply chain.

The cultural changes that DevSecOps brings to software development can almost be more important than the tooling because it brings security concerns into the development lifecycle versus making security the last stop (and the last night) before applications hit production. The DevSecOps culture stresses:

  • Transparency yields trust with sharing between the DevOps and security teams inside enterprises
  • Shared goals and metrics with DevOps and security teams cooperating on shared goals to achieve the desired metrics to achieve compliance and security

While often an ideal, these cultural norms have a lot of applicability to securing the software supply chain. Transparency along the software supply chain builds trust. That can play a couple of different ways. When you build trust with your vendor teams along your supply chain, it becomes easier to share information and collaborate on security and operational challenges. Many of us are also working under challenging personal and professional circumstances during this pandemic. It only helps that you have clear lines of communication open to set expectations. You also want to create an environment where your team, not to mention vendors, can feel safe asking questions and bringing up technology and business issues.

Defense in Depth and Software Supply Chain Security

Another security technique bound to gain attention in the fight against software supply chain hacks is Defense in Depth. Typically, a security strategy of large enterprises with big budgets, Defense in Depth employs multiple layers of security controls so that if one layer fails, other layers remain operating.

No enterprise can say that its systems are 100% secure. That goes for any organization working on your software supply chain. Otherwise, there’d be no need for such drastic security measures as Defense in Depth. Nor would you need system redundancies because attackers wouldn’t be able to exploit your systems. In reality, the state of software supply chain security isn’t going to change much in the next year or even five years. Thus, it behooves security teams across the supply chain to look to security measures such as Defense in Depth to put in “sea walls” with the attitude that eventually, a wave may crash over the wall.

Defense in Depth includes three layers of controls:

  • Physical layer, which controls the physical access to IT systems, including fences and human guards.
  • Technical controls such as fingerprint readers, authentication, and data encryption that prevent access. 
  • Administrative controls are an organization’s policies and procedures to ensure security and compliance requirements are met. Policies include hiring, onboarding, and other processes that govern how technology teams do their work.

There’s no real cultural shift that Defense in Depth brings with it. Yet, it’s essential to consider the introduction of system redundancies to developers and sysadmins’ routine day-to-day work. Specific job roles and metrics would undoubtedly have to adjust to running, managing, and securing redundant systems.

DevSecOps and Defense in Depth

There are many questions about how a coopetion between DevSecOps and Defense in Depth could work for the average enterprise. Both security strategies have their purposes.

The cultural aspects of DevSecOps, especially when it comes to transparency, still relate very well to Defense in Depth. Sooner or later, large enterprises scrutinizing their software supply chain security need to start paying attention to the people aspect of software supply chain security — transparency, insider threat, security training, and communications. 

The people aspects of software supply chain security are bound to come under additional scrutiny in some large enterprises. There are some lessons for everybody to learn from how DevSecOps handles culture and metrics that can transfer over to Defense in Depth.

System redundancies are where DevSecOps and Defense in Depth are at odds. The reference architecture of the typical DevSecOps toolchain is lean and mean, without redundancies. Some organizations even allow their development teams to choose their tools to build out their toolchains.

Somehow, the smart enterprises will cherry-pick from DevSecOps and Defense in Depth to create a solution within budget that can improve their software supply chain security.

Final Thoughts

Risk mitigation around software supply chains is going through an awakening post-SolarWinds. DevSecOps and Defense in Depth both help mitigate a range of significant security risks. The gravity of a software supply chain attack brings home the reality that despite your best preparations, it’s essential to acknowledge that you’ll be hacked. It may not be your enterprise directly but could be one of the vendors along your supply chain. So, you must do the best you can as a security organization. Put in the right tools. Institute best practices. Train your developers and security teams in best practices. Incentivize your vendors to follow suit.  But most of all, you should have a response plan in place to augment your security tools and strategy.

 

5 Critical Job Skills for Software Supply Chain Security Professionals

Posted on by Will Kelly

When auditing your software supply chain security, it’s important not to forget building and maintaining the job skills of your software supply chain security team. Building skills amongst your software supply chain security team and setting expectations for skills and experience amongst your supply chain vendors is a prudent investment as you prepare for a potential attack in your future.

Here are some job skills to build and refresh amongst your technology teams and vendors who make up your software supply chain:

1. DevSecOps

The agile nature of the software supply chain combined with the operational complexities necessitates people with DevSecOps skills and experience.DevSecOps brings your security team and tools into the DevOps life cycle. Designating DevSecOps as a desired job skill for your software supply chain internal and vendor teams also gives your teams a common framework, operational expectations, and terminology that can help improve operations across your supply chain.

Building upon and validating DevSecOps skills is still a nascent activity. There are few industry certifications right now for DevSecOps. The DevSecOps Foundation certification from The DevOps Institute is one certification you can have your software supply chain team members pursue to level set DevSecOps skills across your teams and vendors. If DevSecOps certifications aren’t workable because of timing and availability, then consider the DevSecOps courses on learning sites such as LinkedIn Learning, Cloud Academy, or A Cloud Guru. 

Another option for DevSecOps skills training is to create your own internal training program for all engineers and architects involved in your software supply chain. Your team members who are in charge of software supply chain security need to partner with every vendor team that touches any part of your product during the DevSecOps life cycle to validate that security is an integral element of the vendor’s software delivery organization’s tools, processes, and culture. 

2. Oral and Written Communication (Soft Skills)

Securing the software supply chain of today requires that all the participants have soft skills. Relationship building is critical behind the scenes of software supply chain security as you often have to interact with executive decision-makers, management stakeholders, and counterparts on their vendor teams.

Extending the need for soft skills outside your own enterprise, dealing with vendors and suppliers across your supply chain in times of regular business and crisis situations requires strong oral and written communications skills and even empathy.

Building up soft skills takes practice. While there are various online platforms that offer soft skills training, sometimes the best training is having your managers and team leads set the example so you establish a culture where soft skills are seen as a benefit and not a weakness.

3. Analytical Skills

Software supply chains add additional levels of complexity to software delivery. With more complexity comes more opportunities for things to break down at points across your software supply chain.

Building up analytics skills on your teams can take a couple of forms. Most commonly, it’s thought of as a personal learning pursuit. However, DevOps teams have the advantage of using retrospectives and post-mortems to showcase the analytical thinking skills of their senior team members. These meetings also give you the opportunity to put a structure or framework around troubleshooting and analysis.

4. Cloud Architecture

As the cloud is playing a predominant role in the software supply chain, it’s time to make wise staffing investments in cloud architects. Yes, cloud architects are an in-demand role, as Google shows in their use of trusted cloud computing to secure their own software supply chains.

While Google is an extreme example of how cloud architecture skills play into a software security supply chain security, cloud infrastructure is a growing attack vector. You want to have that skill set in your organization. It’s also a skill set you want across your vendors.

Cloud architecture is an in-demand job skill. Fortunately, cloud architect training options abound. Each of the major cloud services providers has solution architect certifications. Your employees and partners can take the training and even their certification tests online.

5. Documentation

You can’t run a software supply chain with its needs for processes, frameworks, and policies on oral history, email inbox, or Slack channel alone. You need to create a documentation culture with the job skills to go with it. Outside of the security requirements, you place in your vendor contracts and RFPs, written documentation is necessary to help educate your vendors about the standard security practices they must follow to remain a vendor in good standing for your software supply chain.

For example, a best practice is for vendors to document their software and hardware design and build processes to ensure the processes are repeatable and measurable. Such documentation should already be part of the cost of doing business if your product must meet compliance standards such as FedRAMP, Sarbanes Oxley (SOX), or the Health Insurance Portability and Accountability Act.

Building documentation skills isn’t about throwing contract technical writers to write some documentation for your supply chain as part of a rapid-fire one and done project. Rather, documentation needs to become part of team member jobs and vendor requirements. Options for building documentation skills:

  • Embed technical writers or editors amongst your teams to act as writing coaches for technical staff tasked to document the systems and processes they support
  • Create documentation templates for the major document types you require from vendors and provide job aids and documentation kickoff meetings and follow up support
  • Showcase examples of well-done documentation in team and vendor meetings

Final thoughts

As your teams work to improve their support of software supply chain security you’re going to encounter many judgment calls. The job skills in this blog post, all have one thing in common. They all require continuous learning in order for your internal teams and vendors to be successful. As the software supply chain becomes the latest attack vector for nation-state and other attackers, it’s in your best interests to give your teams and vendors the tools they need to succeed.

7 Trends Lining Up to Fight Software Supply Chain Attacks

Posted on by Will Kelly

Software supply chain attacks are going to be forever on the minds of CISOs and DevSecOps teams as commercial and public sector enterprises look for ways to avoid the headlines as the next SolarWinds.

Now’s the time for technology, collaboration, and compliance processes to come together to help protect software supply chains. Here are seven trends that paint a future picture of how it may all work:

1. Compliance Strengthens in the Face of Supply Chain Security

We’ve yet to see a full response from the compliance world — HIPAA, Sarbanes Oxley (SOX), and PCI-DSS —  in the aftermath of the SolarWinds compromise. Responses from the compliance community are certain to come out as healthcare, financial services, and other compliance-governed industries seek advice and counsel about what makes for a compliant software supply chain to their auditors.

One compliance standard built for multi-vendor environments is the United States Government’s Federal Risk and Authorization Management Program (FedRAMP). When you peel away the bureaucracy and the politics, the federal government is just one big compliance play. They have the experience of integrating multiple vendors from large systems integrators, taking small to midsize companies into their software supply chain while maintaining security and compliance. However, despite all the goodness of FedRAMP, there’s little adoption outside of businesses that do government work.

2. Defense in Depth Protects the Software Supply Chain

Defense in Depth is a strategy where you treat every piece of software that you bring into your software supply chain as malicious actors regardless of whether the source where it’s your own developers, external suppliers, or open source. You run and monitor the software accordingly. 

 However, Defense-in-Depth is extremely expensive to do for real.

3. The Rise of Code as an Attack Vector

A software supply chain attack, such as we saw with SolarWinds, will put a renewed focus on code as an attack vector. DevSecOps, with the “shift left” culture it brings, will increasingly become a necessity for development teams up and down the software supply chain. Part of the shift-left culture is to equip your developers with lightweight tools to use locally to scan their code.

You can expect to see other mitigation strategies on the rise such as developing a robust code composition strategy with a detailed software bill of materials (SBOMs). Such strategies with a fully documented and verified change of custody for all software code entering the supply chain. Your developers can also run a secrets calling tool on all code repositories and include active monitoring. You should also have your developers or in-house cybersecurity team search for your code in public Git repositories, especially GitHub and GitLab. Finding your code once means there’s bound to be more of it out there.

Another strategy is to invest in tools to monitor code integrity and git misconfiguration. Deploy these tools in your DevSecOps pipelines and ensure that your supply partners are using the same or similar tools in their DevSecOps toolchains.

4. OSS and the Future of Supply Chain Security

There are bound to be more questions than ever about open source software (OSS) in enterprise software supply chains across industries and governments. While OSS is a foundation to leading DevOps, DevSecOps, and cloud-first initiatives, it will not stop technical and business leaders from asking even more questions about sourcing this critical software.

There are still more questions than answers about what the post-SolarWinds world may look like for major OSS projects prevalent in the enterprise. It may lend even more credence to the Red Hat business model and perhaps breed more companies taking ownership over some more facets of OSS.

Some in the OSS community are calling for more corporate open source citizenship. For-profit companies and even government agencies donate money, time, and expertise back to the OSS projects they use most to improve the project’s code security.

On the security front, it could mean that enterprises depending on OSS enlist mandatory code scanning tools to vet all the open source code entering the toolchain. It could lead to an onboarding process for open source code.

5. DevSecOps for Everybody!

DevSecOps could become one cost of entry for partners in a software supply chain soon. While criticisms about the validity of DevSecOps abound in some technology industry circles, the current situation offers the DevSecOps movement a time to prove itself.  The benefits of well-executed DevSecOps across software supply chain providers include:

  • A common language for developers, security, and operations teams
  • Improved access to actionable data from backend development, build, and QA systems for reporting to stakeholders and auditors
  • A development model that relates well to iterative software development and automated security testing at each phase of the development cycle

In the future, larger enterprises may demand contractually that all their suppliers follow a DevOps/DevSecOps model of development. However, such standardization of practices could be difficult, if not impossible, to enforce in all reality. However, startups already standardized on agile and DevOps gain a leg up if they have salespeople who can bring home large enterprise accounts.

6. Transparency Grows in the Software Supply Chain

DevOps and DevSecOps have driven home the need for transparency in the development lifecycle. Transparency needs to grow throughout the software supply chain during 2021 and beyond. One solution to make that happen is in-toto — a software supply chain security framework– that includes current integrations with Git, Docker, Datadog, and some other open source build tools.

7. Zero Trust across the Supply Chain

As concerns over software supply chain security grow in 2021 and beyond, zero trust security solutions may come to bear in the next generation of software supply chain security. However, there are some caveats to this approach. Zero trust security is still an emerging category (albeit with great potential). My colleague, Andre Neufville, wrote about how zero trust security can protect containers. It’s a technology bound to find itself in the software supply chain of the future because it treats all code as equally malicious while giving developers and security teams the tools and processes to help mitigate the associated risks.

Final Thoughts

There’s no denying that software supply chain security will forever remain a challenge. Given that,  it doesn’t mean that your organization can’t be forward-thinking in the technologies and strategies that you put in place to mitigate risks across your software supply chain