da Agency

What is the most important but often forgotten asset in a digital transformation? (Hint: you’re paying them)

So your organization is embarking on a digital transformation journey, and you’re in charge of making it all happen. You have buy-in from senior leaders; you’ve articulated the North Star, defined clear objectives, identified the metrics for success, created processes and built frameworks to make it all happen. Additionally, you’ve already started assessing both the new technology and how it would impact your digital and customer experience. Budget in hand, off you go delivering on your plan. But is there something missing?
Rarely do you see mention of “people,” the most valuable asset to any organization and the main reason behind the success of any digital transformation if you ask me. Digital transformation journeys are not an easy undertaking due to the arduous impact it has on teams. More common challenges include:
Communication breakdowns
Organizations have a tendency to keep communication at a high level and shy away from providing details, leaving out pertinent information that employees value the most. Often employees want to know how the transformation will impact them directly and their day to day. It’s important for them to understand the vision as well as the path to get there.
Steep learning curve
Undertaking digital transformation gives an organization a competitive edge, accompanied by the implementation of state-of-the-art technologies. At the same time, the adoption of modern technologies also requires a modern mindset. The more changes occur, the more people will have to learn in order to be successful using the new technologies. For employees to level up their skills and adapt to the changes, they need a rigorous training plan to ensure they have time capabilities to adapt to upcoming changes.
Change is hard
Empathy goes a long way and it’s important to remember that change is hard on everyone. Each individual on the team will have their own unique journey so each will require personalized support of varying levels. Some will see the upcoming change as positive and champion it while others will need time to process and accept it. Establishing a continuous learning culture enables your company to provide the necessary support for each employee and their individual journeys.
Smoothing the digital transformation for employees
Ensure you have the following tools in your toolbox when embarking on your digital journey so that you can support your people through to success:
Have regular check-ins
A huge part of gaining buy-in is addressing any resistance or fear for the next phase of the journey. Having regular check-ins will help you create a safe space for anyone to share what’s on their mind. This key feedback will help you fine tune the current action plan or even make larger pivots if needed.
Change management
Having a dedicated change management resource (or even more than one) is absolutely essential. They enable you to communicate your vision to various stakeholders and audiences within the organization and gain buy-in. They also help in various other ways: supporting your leadership, creating champions within the organization, and being that confidant who can meet with various layers and create a much-needed feedback loop.
Training
Training can help mitigate transformation challenges and comes with additional benefits to your teams, including:

Increase in employee engagement
Boost in employee motivation
Improvement in culture
Enhancement of the customer experience
Acceleration in productivity

Ensuring that the people in your organization are trained on new technologies is an essential part of the implementation of any successful digital transformation. According to Gartner, high-performing teams are 53% more productive with training.
In the end, it comes down to making sure that while you transform your company, you’re also transforming your people, and you need to ensure that they have the support, organization, and training they need to be successful — and to make your initiative successful.

Maroquine Aziz holds a Master’s Degree in Business Administration (MBA) from the University of Laurier and a Bachelor’s degree in Information Systems from the University of Toronto. Her passion for innovation and thirst for knowledge have led her through a multi-disciplinary career path spanning various industries, including education, environmental, e-commerce, insurance, healthcare, and research. As a visionary transformational leader, Maroquine brings over 15 years of strategic leadership experience acting as a methodology expert and facilitator supporting new product and service initiatives in the fields of Technology and Operations. Coaching and mentoring teams have been instrumental to achieving goals; her specialty is her ability to continuously engage and raise the bar to drive excellence across organizations. A changemaker at heart, she constantly strives to solve complex business challenges and achieve success.
Quelle: Mirantis

da Agency

The Impacts of an Insecure Software Supply Chain

Today, software regularly integrates open-source code from third-party sources into applications. While this practice empowers developers to create more capable software in a shorter time frame, it brings with it the risk of introducing inadequately vetted code. How aware are we of the security of our open-source code?

Most of us use pip or npm to freely install software, making decisions based on functionality and support. Efficiency is the goal when we have delivery targets to meet. If we choose not to use open-source solutions, we miss out on their significant productivity benefits. But, if we decide to use open-source solutions, we take the chance of potentially introducing insecure components into our software supply chains and must mitigate any risk with the right tools and processes.

So what is the software supply chain? The software supply chain comprises the steps it takes to develop code before it makes its way into an organization’s application. The chain includes all open-source contributors who wrote the code, the dependencies the code relies on, the repositories where developers downloaded the code, and the organization’s internal review. Each link in the chain represents a potential weak point where unsafe or malicious code can make its way into a production application. 

What Can Go Wrong

Google’s security policy points out that “if an attacker successfully injects any code at all, it’s pretty much game over.” Unfortunately, with continuous deployment (CD) becoming more commonplace, the window to spot such attacks before releasing infected code to users has narrowed.

Attackers’ goals are varied. Hijacking resources for cryptocurrency mining, harvesting username and password combinations for credential stuffing, and data scraping are just a few examples. The consequences are often dire.

Let’s explore some of the potential risks of using open-source solutions.

Common Forms of Attack

Malicious software posing as genuine packages routinely shows up in package management software. Two types of supply chain attacks take advantage of modern software’s numerous dependencies: typosquatting and dependency confusion. In both, the assailant uses a variety of tactics to trick the developer or management software into downloading a dependency file that can execute malicious code. 

Typosquatting

Typosquatting relies on the proximity of keys on a keyboard and common misspelling to gain entry. This method of attack transcends programming language bases. Since the early days of the web, domain name typosquatting has been a problem. Package and image deception has become increasingly prevalent, banking on developers’ quick fingers.

In typosquatting, a publisher has uploaded a package with a misspelled name. The misspelled name is so similar to the original package’s that the developer fails to notice they have misspelled the word, unknowingly downloading malicious code.

Dependency Confusion

Dependency confusion exploits the mix of private and public dependencies that software uses. Hackers typically inspect package.json files for Node.js applications to find internal unclaimed packages on npm. They create malicious packages with this same namespace, and automated developer tools install these external malicious packages instead of the intended internal package.

This tactic isn’t limited to npm. For example, Python’s pip displays insecurities ripe for exploitation. Here, a hacker can register a package on PyPi with the same name as an internal package, identified in a requirements.txt file. At registration, they select a higher version number than the genuine package. When this higher number is in builds that include –extra-index-url, it takes precedence, and this seemingly newer version replaces the older.

Like typosquatting, dependency confusion is a problem for all languages. Similar attacks could happen with a Maven pom.xml file or Gradle settings file in Java or a .csproj file referencing NuGet packages in .NET. Tools incorrectly substitute the code, leaving our application vulnerable.

It’s important to remember that these issues can be present deep in the chain, in transitive dependencies. In the diagram above, we can see that an attacker has targeted a dependency, of a dependency, of a dependency. This nesting makes our ecosystem unmanageable and challenging to audit. 

We may trust our developers not to make malicious codebase changes and perhaps feel content that a four-eye review policy will protect our software. When a dependency gets upgraded, we trust that someone else is carrying out reviews with our rigor. But this may not be the case for packages maintained in small teams or by individuals.

An Example Scenario

A malicious actor creates a seemingly innocent package, like some utility functions. Let’s call this Package X.

They then publish their code to a package distribution site. Remember, just because code is inspectable on GitHub doesn’t necessarily mean it’s the same code on the package management site.

They use Package X as part of a pull request into the code for Package Y, fixing minor bugs on open-source projects. Their genuinely-useful bug-fix has pulled in the malicious dependency (Package X), and presto! The malicious code is in the repository.

If our code uses Package Y, then our software inherits the vulnerability in Package X.

Organizations must update their open-source code constantly to mitigate the risk of hidden vulnerabilities. These organizations must also use detection methods such as automated vulnerability scanning to identify known vulnerabilities before they cause damage.

With global news coverage quick to publicize any data or security breach, these incidents can damage an organization’s reputation. Rebuilding that trust is highly challenging. 

Empowering Developers to Secure Your Supply Chain

All of the security risks that come with development means developers need access to tools that make security as easy as possible for them. Luckily, Docker seamlessly integrates security measures across our platform to help mitigate risks and secure the software supply chain. The first step is attestation and verification. To establish trust, we must verify code and not make any assumptions about its security. 

Docker’s Image Access Management feature, available to Docker Business users, enables organizations to control where they get their software. This approach shifts the control of access and permissions from developers to the site level, with toggle options to easily set options and role-based access control (RBAC) available to manage authorization at scale. This control helps ensure developers are only using approved and secure images.

Image Access Management is also a good way of guaranteeing the sources are legitimate. When your business has hundreds of developers, tracking what each software engineer is innocently installing becomes challenging. Docker Business users get an audit log that records the creation, deletion, and editing of teams and repositories to enhance visibility.

To help developers make better container image decisions, Docker provides a visual way of validating images via badging in Docker Hub. These badges are specific to Docker Verified Publisher Images and Docker Official Images and signal to developers that what they’re pulling is trusted, secure, and ready for use.

Docker also provides vulnerability scanning tools via our security partner, Snyk. Developers can use the Snyk scanner right in their CLI for the insight and visibility they need into the security posture of their local Dockerfiles and local images. This includes a list of Common Vulnerabilities and Exposures (CVEs), the sources, such as OS packages and libraries, versions in which they were introduced, and a recommended fixed version (if available) to remediate the CVEs discovered. When this step is automated, we no longer rely solely on our developers to manually scan for insecurities.

Gaining Peace of Mind

Returning to our Package X example, we now have multiple layers to prevent that worst-case scenario:

Image Access Management ensures that our developers can only pull base images from trusted, verified sources.Role-Based Access Control enables developers to reduce the blast radius by controlling which developers can bring in new content and potentially isolating the breach to a single team’s work.Vulnerability Scan automatically scans for CVEs when we build a new image. To quickly resolve our insecure dependency issues, Vulnerability Scanning vets and flags dependencies for our developers and offers remediation options.Audit Log provides three months of history capturing all activities. This record helps organizations discover all affected internal supply chains quickly.

This layered approach to security offers increased opportunities for checks. While vigilance and manual checks are still ideal, it’s reassuring to have these tools available to help prevent and combat attacks.

Conclusion

In this article, we’ve explored the genuine supply chain security problem, one that President Biden has even addressed.

By targeting an app’s dependencies, cybercriminals can reach multiple organizations with the hope of evading scrutiny. It’s often the easiest way to break in when organizations are locked down. Everyone is a potential target, and attacks can have wide-reaching implications. Assailants seem happy to play the long game and use social engineering to gain access, perhaps offering their time as repository maintainers. As developers and automated tools integrate components into systems, there become multiple points where an adversary could inject malware.Docker offers a robust suite of tools for vetting open-source code and dependencies before making their way into an application. Docker Business enables software development to continue to benefit from the productivity gains of containers without being hampered by security concerns.

Get started with Docker Business to discover how Docker helps keep your business safe and secure.

DockerCon2022

Join us for DockerCon2022 on Tuesday, May 10. DockerCon is a free, one day virtual event that is a unique experience for developers and development teams who are building the next generation of modern applications. If you want to learn about how to go from code to cloud fast and how to solve your development challenges, DockerCon 2022 offers engaging live content to help you build, share and run your applications. Register today at https://www.docker.com/dockercon/
The post The Impacts of an Insecure Software Supply Chain appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/