devopsy.kinsta.cloud

Tag: dependencies

Proactive Dependency Management: Reducing Risk and Improving Software Quality
In modern software development, open-source components or dependencies are fundamental to rapid innovation. Developers typically choose these components based on personal experience, research or guidance from technical leads. However, once integrated, these dependencies often recede into the background.

Over time, these dependencies can accumulate technical debt, turning into neglected assets that may introduce bugs or security vulnerabilities.

Proactive dependency management is crucial for maintaining secure, high-quality software. I recently discussed this topic at All Day DevOps (ADDO) 2024. Read further to learn more about common pitfalls, key statistics and best practices to stay ahead of potential issues.

The Hidden Cost of Neglected Dependencies

While software dependencies play a vital role in modern applications, they can also introduce significant risks if not managed proactively.

Here are some key statistics that illustrate the impact of neglecting dependency management:
- Each application has six to 10 direct dependencies, which balloon to 180 total dependencies when accounting for transitive dependencies.
- 80% of application dependencies go un-upgraded for over a year, exposing software to bugs and security vulnerabilities.
- Each project releases an average of 15 new versions per year, and developers spend about two hours on each dependency version upgrade.
- This adds up to 300 hours per application per year — a significant investment of time that could be reduced with better automation and management
Vulnerabilities Lurking in Outdated Dependencies

One of the most critical issues with unaddressed dependencies is their potential to introduce security vulnerabilities.

Even when fixes are available, many organizations fail to update their dependencies on time. A full 96% of vulnerable releases downloaded had a fixed version available.

The notorious Log4Shell vulnerability of the Log4j component is a prime example. Despite the well-publicized risk and the availability of patches, 13% of Log4j downloads in 2024 are still vulnerable versions.

This statistic underscores the importance of staying vigilant about dependency updates, especially with critical components that could expose applications to significant risks.

Automating Dependency Management for Reliability and Security

Proactive dependency management can be a daunting task, but automation offers a solution. Automated systems can monitor dependencies and flag updates, helping teams stay ahead of vulnerabilities and ensure compatibility.

However, not all automation is equal. To be effective, automated solutions must take into account API compatibility to prevent broken builds and reduce upgrade time. Without this, a typical two-hour upgrade can balloon, disrupting other priority work.

Another valuable input to automate solutions is the popularity of open-source components. Popular components exhibit 63% more identified vulnerabilities but also address 54% more and resolve them 32% faster than less-known components. While popular projects undergo more rigorous scrutiny, they typically make updates more accessible, which becomes incredibly powerful when those updates can be integrated through automation.

The Impact of Transitive Dependencies

One of the most challenging aspects of dependency management is the ripple effect that changes made to direct dependencies can have on transitive dependencies.

Managing only 10 direct dependencies can impact up to 170 transitive ones, forming a complex web of interconnected components that require vigilant monitoring and updates. Overlooking this intricacy can lead to significant issues, such as build failures, bugs and security vulnerabilities.

For this reason, automating dependency management is essential for reducing the risk of unexpected failures. Automated tools that provide visibility into the full dependency graph enable developers to assess the impact of updates and take action before problems arise.

Best Practices for Proactive Dependency Management

A key takeaway from the presentation is that proactive dependency management is not just about staying on top of updates — it is about creating a strategy that minimizes risk while improving software quality.

Here are a few best practices that can help:
- Automate dependency updates: Leverage automation tools to track and update dependencies across your applications. By automating routine updates, you can reduce the manual workload on your team and minimize the risk of vulnerabilities.
- Monitor for vulnerabilities: Regularly scan your dependencies for known vulnerabilities and ensure that you are updating to secure versions as soon as they become available. This is especially important for popular open-source components, which are frequently targeted by attackers.
- Assess API compatibility: Ensure that your automation tools account for API compatibility to avoid broken builds and wasted time. This will help keep your development process smooth and efficient.
- Focus on transitive dependencies: Don’t just manage your direct dependencies — make sure to monitor the transitive dependencies that they introduce into your These hidden dependencies can often be the source of critical issues if left unmanaged.
Staying Ahead of Technical Debt and Security Risks

Ignoring your dependencies is not an option. The statistics presented show the consequences of failing to manage dependencies proactively. By adopting best practices and embracing automation, you can reduce technical debt, improve software quality and avoid costly security breaches.

Managing dependencies isn’t just best practice, it is an essential ongoing process. Implement these strategies in your projects to stay ahead of potential issues and ensure your software remains reliable, secure and up to date.
November 13, 2024
The Practicalities of Open Sourcing

I’ve been deeply immersed in the world of developer products for the past decade, and let me tell you, I’ve been quite the open source enthusiast. Over the years, I’ve had the pleasure (and occasional pain) of shepherding open source projects of all shapes and sizes. It’s almost become a rite of passage in some teams – the moment when your APIs and libraries step into the spotlight. After all, customers want to know what kind of software is going into their code concoctions. But, let’s be real, I’ve also witnessed open source used as a bit of a smoke-and-mirrors exercise. So, if you’re contemplating the daring act of open sourcing your projects, here are some things to know before you set out.

Manage Your Expectations of External Contributions

If I had a penny for every open source manager disappointed by unrealistically high hopes of a flood of external contributions, I’d have enough pennies to… well, still not meet those expectations. The truth is that the majority of open source projects never witness a bustling community of external code contributors. Just because your software is popular doesn’t guarantee open source success. Open source is like nurturing a garden; it takes time and effort to grow. Building a community involves shaping your APIs, fine-tuning functionality, defining boundaries and managing expectations. Expecting an avalanche of external contributions in the early days is a recipe for disappointment.

OSS can be Intimidating

While developers generally relish the idea of sharing their work with the world, I’ve stumbled upon situations where junior engineers were a tad shy about coding in the public eye. In some cases, we’ve had to delay open sourcing because engineers wanted to tidy up their work before unveiling it to the world. Especially if your team is a mix of early-career engineers, it might be easier for senior team members to offer coaching and conduct code reviews in a more private setting without the intimidating public glare.

Issue Triage and the Support Price Tag

In theory, maintaining a public issue tracker is distinct from open sourcing the code itself. In practice, these two are closely linked. Opening up your product’s priorities to the public means putting them on display alongside real interactions and feedback from customers. This doubles the importance of being responsive to customer issues, efficiently triaging them, and setting the right external expectations. For successful open source projects, this is a genuine labor of love.

The Need for a Private Mirror

There comes a time when you need to work on something in private, perhaps in preparation for a grand launch event. Unfortunately, last time I checked, GitHub doesn’t offer private branches. You might find yourself wrestling with the challenge of setting up a private mirror. What happens when you’re juggling a significant launch on an internal mirror while simultaneously managing customer bug fixes on the open source repository? Mirrors are like trying to keep two squirrels synchronized – challenging.

Saying Goodbye to Obscurity

Some software on the internet relies on obscurity for its security. Open sourcing it would be like sending hackers an engraved invitation to a party they don’t need directions to.

Unfriendly Dependencies

If your project is tangled up with third-party libraries sporting licenses that are less open source-friendly than a cactus in a desert, you’re in for a headache. I sincerely hope you don’t run into this, as unfriendly licenses often come hand in hand with unfriendly people.

Navigating the Ecosystem: Dealing With Dependency Upgrades

Open source codebases often face a common challenge – the relentless pressure to keep dependencies up to date. This is especially true for libraries and APIs embedded in customer applications, where managing transitive dependencies and supporting older versions can be a delicate balancing act.

Teams typically adopt one of two approaches. Some isolate these dependencies in a separate namespace to avoid conflicts, while others enforce a policy to always use the latest versions. Regardless of the chosen method, open source projects frequently encounter external contributions aimed at upgrading dependencies. Handling such contributions publicly, and sometimes declining them, can be a tricky task.

Maintainers must navigate this terrain diplomatically, explaining that the proposed change might not be suitable for all users by paraphrasing, “You’re not our only customer, and this could affect many others.” This balancing act showcases the challenges of maintaining open source projects in a dynamic ecosystem.

Unexpected Benefits

Now, let’s not forget the unexpected perks I’ve stumbled upon during my open source adventures. After all, I’ve done enough complaining.

● Modernization: Open sourcing often nudges you to modernize your build and deployment pipelines because, frankly, it’s easier to get them right than to get them wrong.

● Privacy and security: Open sourcing can make addressing questions about privacy and security a breeze. In an era of regulatory crescendo, it’s your golden ticket to showcasing your data-handling ballet. It’s like saying, “Hey, world, check out our moves!”

● Building trust with customers: I’ve found some outstanding team members through successful open source projects.

● Trust in open standards and code: Organizations are increasingly placing their trust in open source software. Your larger customers might care about this more than you’d imagine.

And that’s a wrap, folks. Best of luck with your open source journey!

February 13, 2024
Checkmarx Report Details Havoc Caused by ‘Everything’ Package on NPM Registry

Checkmarx this week released a report detailing a package distributed via the NPM registry that cripples any machine that is used to download it.

Dubbed the “Everything” package, a user known as PatrickJS, also known as gdi2290, uploaded a package that has more than 3,000 sub-packages. Each sub-package is designed to split dependencies into chunks and to depend on all publicly available NPM registry packages, resulting in transitive dependencies that disrupt pipelines and exhaust storage space.

Following significant effort, The Everything package has since been removed from the registry, but the perpetrators did create a domain where they showcase their handiwork. Whether the Everything package was created as a joke to be played on developers or has some other malicious vandalistic intent is unclear.

Jossef Harush Kadouri, head of software supply chain security for Checkmarx, said these types of incidents are likely to happen from time to time because there is no process for reviewing packages prior to them being loaded into a registry. In fact, a similar incident previously occurred when a “no-one-left-behind” package by Zalastax that was dependent on every publicly available npm package was uploaded in the registry.

It’s only when an issue is identified that the maintainers of the NPM registry will remove a package. Those maintainers simply lack the resources and tools that would be required to scan every package, noted Harush Kadouri.

Heading into 2024, it will be incidents like these, along with vulnerabilities found in NPM packages, that will serve as an impetus for reviewing the workflows that make up an organization’s software supply chain. For well over a decade, developers have been downloading software components from various repositories with little to no regard for vulnerabilities. As more of those vulnerabilities are exploited, organizations that rely on that software are now requiring providers of applications to provide visibility into the provenance of the components used to construct it. The overall goal is to make it simpler to remediate applications, especially when a zero-day vulnerability is discovered.

In the meantime, organizations would be well-advised to curate a repository of software components that have been vetted. Developers can still readily access those components to build applications, but there should be fewer downstream application security issues if the components residing in that registry have been scanned. If developers are allowed to directly download packages and components from a public registry, it’s only a matter of time before an application security issue is going to arise.

Hopefully, as organizations adopt DevSecOps best practices, the number of application security issues encountered will steadily decline. Each organization will need to determine how far left to shift responsibility for application security toward developers, but one way or another, software supply chains need to be better protected.

Of course, the issue will ultimately be forced by regulations that are becoming increasingly more stringent. Once the first fines are levied, it won’t be long before just about every organization that builds and deploys software will quickly move to limit their liability as much as possible. The challenge and the opportunity now is to proactively secure software supply chains today before any remedy that might be imposed on an organization disrupts application development workflows tomorrow.

January 5, 2024
The Case For an API-First SCM

Somewhere around a decade ago, about the time DevOps really started to manifest, we began seeing technology companies—including some of the largest ones today—investing heavily in their APIs.

API-first companies managed to rapidly gain widespread adoption because of the benefits of being API-driven. Everything from automation and scalability to flexibility, performance, speed and monetization. Once DevOps thinking made it increasingly clear that automation would solve problems like human error and increase performance and velocity, creating more machine-to-machine interaction became a critical factor in software delivery—because the problem in the technology world was not innovation, but rather integration.

Twilio is a prime example. The company became famous for its API-driven approach to customer management and even had a famous Silicon Valley billboard trumpeting their success. They changed the game for customer communication for some of the largest companies in the industry, from Netflix to DoorDash to Coca-Cola, by making communication completely invisible to users. These APIs largely served developers by unifying communication on the backend and providing powerful customer-facing capabilities on the business side. But they’re not the only ones.

API-driven companies managed to disrupt entire markets nobody imagined could be disrupted, such as Stripe for payment processing and Slack for immediate communication (their former head of developer relations, Amir Shevat, said that Slack’s developers were literally measured by their API’s active tokens). Companies that harnessed the power of their APIs saw unprecedented growth over the last decade due to the integration power they unleashed.

Today, there really is no self-respecting dev-first technology that doesn’t invest heavily in the robustness of its APIs. There are even entire companies today built around API integrations—from marketplaces like Rapid API to security companies like Akita Software to companies like Kong that focus solely on simplifying API gateways.

The API-First Dev Tool Revolution

The same transformation that disrupted various business industries is now beginning to take center stage in the technology and dev tools space. This is also part of the developer experience revolution that is the stimulus for all the nifty dev tools in the first place. As developers become the new decision-makers—masters of their own domain—and are no longer being forced to adopt and use technology someone else purchased for them, the experience of using these tools impacts their choice of whether or not to add these tools to their chain. This means that those creating the tools today need to deeply understand the developer’s workflow and optimize their products for this user persona.

This very same evolution that typical tooling underwent is now impacting age-old tooling in the developer ecosystem—and developer pain and friction are starting to come to the forefront. This includes the need for better and more robust API capabilities, “as-code” (infrastructure-as-code, testing and security) tooling, low-code/no-code and code variations and much more.

It’s interesting to see that, even with the cloud-native and DevOps revolution, our most core developer tool—our source code management—hasn’t really changed much in the last 20 years. Git remains ubiquitous, but its design is optimized for developer workflows from two decades ago. It’s long past time for an API-first SCM, and there are a number of use cases that can benefit from better APIs.

Evolution and Anatomy of APIs to be Git-Native

Even with the most exciting innovations we’re seeing from Git SaaS tools like GitHub and GitLab—from Co-Pilot to Codespaces, pipelines and more—they’re only as strong as the technology they are built upon. As the world evolves, this fundamental weakness is proving to be a sort of kryptonite.

Despite Git being an old-school, monolithic tool with proprietary protocols, Git hosting providers like GitHub, GitLab and Bitbucket have invested a lot into making their services API-driven to cater to tool integration. True, each has its own API, which drove some players integrating with the service (especially in the early days) to integrate via an SDK rather than an API.

GitHub itself provides a variety of APIs—from the simpler REST through the more elaborate GraphQL. These APIs provide you with the ability to do pretty much anything, but are somewhat cumbersome for some use cases. To deal with the core Git functionality, you are required to directly manipulate objects in the Git database.

Code Deployment and GitOps

As engineering organizations grow, the need for greater control of code and infrastructure resources has become a real pain—and this is where GitOps provided the methods and the tools to support automated policy management at scale. This automated policy and governance is largely enabled, machine to machine, via APIs, and many of its controls are built on code and configuration files that are hosted via Git (hence its name: Git Operations).

When using this methodology, a configuration change is first committed to Git (as the single source of truth that will apply changes in all the relevant places). Only then does this trigger automatic processes to apply these changes universally. In some cases, these automatic processes have to commit files to Git via API.

Another area where SCM APIs play a key role is versioning and release management. DevOps teams need to manage the release of new versions of their applications, including creating release notes, tagging releases and creating release branches. These processes, which sometimes take place multiple times every day, include many steps and require accuracy—a comprehensive suite of efficient APIs is critical for such an operation.

UX Customization

Today, there’s a huge diversity of stakeholders in modern engineering processes, particularly in the context of game development, but this is also true in any kind of web-based or UI-based engineering, as well. Today, product and design are an integral part of engineering processes, but Git still remains the domain of developers.

There are times when you’d like to have a unified interface for your asset management that pulls data from multiple APIs and sources—such as Git for source control and Google Drive for large files. The added benefit is to abstract and decouple the underlying technology from the user experience and interface so that users can be free to migrate and move between their technologies of choice. This is true whether at the SCM or the storage level without having to change the interface that the team is accustomed to.

APIs that efficiently perform the full set of SCM functionality allow developers to use a single backend for managing code versions while still providing end users with the desired experience, regardless of what that might be.

Versioning-as-a-Service

SaaS products have made it significantly easier to manage and maintain our services through simple UIs and dashboards. However, this simplicity also has a tradeoff. Have you ever made a simple configuration or code change, quickly regretted doing so and then attempted to revert it via your SaaS console? In most SaaS apps that aren’t managed as code, this happens all the time—from Okta to Datadog and many others. Without the benefits of “as-code” and the version control that comes with it, reverting changes is nearly impossible.

The most you can achieve is “undoing” a previous configuration—if you can still catch it with a CTRL+Z—simply because engineering didn’t bother (or did not have the resources) to implement versioning. Imagine if this could come as a service for all of your SaaS applications!

For software developers, API-based version control will unlock the possibility of easily incorporating rich version control capabilities into their product—in the same way they can currently use other capabilities such as database, file storage, etc.

The World is Ready for an API-First SCM

TL;DR: API-first models have delivered some of the greatest innovations that ‘dinosaur’ industries—from payments to communications—needed to move faster and do so securely. It is almost laughable that the technology industry has inherent limitations due to a core technology that has a legacy design. This should not be a technology limitation we should accept.

Our source code should be able to be controlled, manipulated and transformed via API to remove human toil from places it isn’t really needed and free people to focus on higher-order problems. With the widespread adoption of generative AI and smarter machine overlords, we’ve discovered that there are many formerly manual tasks that we can offload to machines. Free SCM APIs to unlock the next generation of innovation—because soon there will be more machines than humans to manage them. APIs are the key to tapping into this power.

June 16, 2023
Report: Most IT Teams Can’t Fix Open Source Software Security

Lineaje, a provider of a platform for securing software supply chains, today published an analysis of 41,989 open source components embedded in the top 44 popular projects managed by the Apache Software Foundation (ASF). That analysis found more than a quarter (26%) of vulnerabilities are not patchable by the application development team that deployed them.

In addition, the report found that 64% of the vulnerabilities analyzed have no patch as of yet. Overall, 68% of the vulnerabilities analyzed are due to dependencies created when an open source software project included a component or package developed by another open source project maintainer.

Lineaje CEO Javed Hasan said that means that 90% of open source dependencies are transitive, in the sense that they are created when maintainers of a project included a vulnerable open source component created by another entity. Only 10% of the vulnerabilities discovered by Lineaje are the result of a dependency that an application development team could actually address on their own, he added.

Overall, the report found a full 82% of components that are relied on to build open source software are inherently risky due to vulnerabilities, security issues, code quality or maintainability concerns. In addition, 5% of components failed a basic integrity check, with 3% having no known origin.

Open source software is not created equal no matter what consortium is overseeing its development, noted Hasan. Unfortunately, there is no universally accepted method for validating the integrity of open source software, so application development teams should proceed with caution whenever employing open source software, he said.

The challenge, of course, is that developers have been reusing open source software within applications for years now. It’s only in the recent wake of breaches involving open source software that organizations have been taking a harder look at how applications are developed.

The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is now at the forefront of an effort to better secure open source software by focusing on 10 streams of investment that, in total, will require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure open source software is secure when deployed in a production environment belongs to the organization that deploys it.

Hopefully, following a recent executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead—assuming, of course, the organizations that rely heavily on open source software make more substantive contributions to securing it. In the meantime, organizations can count on the fact that cybercriminals have taken note of the vulnerabilities in applications that can be traced back to flaws in a wide range of open source software.

April 17, 2023
Running Serverless in Production: 7 Best Practices for DevOps
Serverless in production refers to the deployment and use of serverless architecture in a live, production environment. In this context, serverless refers to a cloud computing paradigm where the cloud provider manages the infrastructure and allocates resources as needed to run and scale applications and services.

In a serverless production environment, applications and services are broken down into individual functions triggered by events, such as API requests or changes in data. These functions are executed in response to these events and the cloud provider is responsible for managing the underlying infrastructure, including servers, storage and network resources.

In this article, I’ll describe some of the key use cases of serverless in production and provide important best practices DevOps teams can use to run serverless in production safely and effectively.

Use Cases of Serverless in Production

Serverless technology has emerged as a popular choice for delivering various applications and services in production. Here is a brief overview of serverless in production for four use cases.

Microservices

In a microservices architecture, an application is divided into small, independent services that can be developed, deployed and scaled separately. Serverless allows each microservice to be deployed as a separate function, triggering the function only when needed and scaling it automatically based on demand. This results in a cost-effective and flexible solution for microservices, as the user only pays for the exact amount of computing resources used by each function.

IoT Devices

Internet of things (IoT) devices generate large amounts of data, which need to be processed and analyzed in real-time. Serverless functions can process IoT data as it is generated, allowing for real-time analytics and decision-making. With serverless, the processing and analysis can be scaled dynamically, handling spikes in data volume without the need for infrastructure management.

Multimedia Processing

Multimedia processing tasks, such as image and video compression, often require significant computing resources. With serverless, these tasks can be performed as functions triggered by events such as the upload of a new image or video. The serverless functions can scale automatically to handle large amounts of data, reducing the costs associated with infrastructure management and increasing efficiency.

This function-as-a-service (FaaS) is often used for storing and processing user inputs and other data types. For example, FaaS can be used to execute specific processes according to the category of media uploaded by the user. It’s easier to build these services because the developer can write one function that is applied to multiple processing tasks.

APIs for Mobile and Web Applications

APIs are an essential component of many web and mobile applications, providing access to the underlying data and services. Serverless functions can build and deploy APIs, providing a cost-effective and scalable solution. The functions can be triggered by incoming API requests and automatically scaled based on demand, allowing for fast and reliable API access for users.

FaaS is especially useful for RESTful applications and event-driven architectures. Containers are also useful for performing processes like API calls, but serverless functions are best suited for highly fluctuating volumes of traffic.

Best Practices for Running Serverless in Production

1. Monitor the Serverless Environment

Serverless monitoring refers to the process of monitoring serverless applications and infrastructure, including serverless functions and event-driven computing services, without the need for dedicated servers or virtual machines. In a serverless architecture, computing resources are dynamically allocated and managed by the cloud provider, so there is no need for organizations to manage and maintain their own servers.

Serverless monitoring involves monitoring various aspects of serverless applications and infrastructure, including function execution, resource utilization and performance metrics. The goal of serverless monitoring is to identify and resolve issues that may impact the performance and reliability of serverless applications and to optimize resource utilization for cost efficiency.

By implementing serverless monitoring, organizations can ensure that their serverless applications and infrastructure are performing optimally and that they can quickly identify and resolve any issues that may arise. This helps to improve the reliability and cost-effectiveness of serverless computing and enables organizations to take full advantage of the benefits of serverless architecture.

2. Implement Authentication

Serverless authentication refers to the process of authenticating users and applications in a serverless architecture, where computing resources are dynamically allocated and managed by the cloud provider. In a serverless authentication model, authentication is managed through cloud-based services and APIs without the need for dedicated servers or virtual machines.

By implementing serverless authentication, organizations can ensure that their serverless applications and services are secure and that users are only able to access the resources that they are authorized to access. This helps to improve the security of serverless applications and services and reduce the risk of security breaches.

3. Ensure Security with API Gateways

API gateways provide a centralized point of control and security for incoming API traffic. API gateways allow for the implementation of authentication and authorization mechanisms, such as OAuth, to control access to serverless functions. This ensures that only authorized users and clients can access the functions, reducing the risk of unauthorized access.

API gateways can also manage incoming API traffic, such as rate limiting and request filtering, to prevent overloading the serverless functions and protect against denial-of-service (DoS) attacks. They perform real-time threat detection, identifying and blocking malicious traffic before it reaches the serverless functions. This includes protection against other common attacks such as cross-site scripting (XSS) and SQL injection.

Finally, an API gateway can enforce encryption for incoming and outgoing API traffic, ensuring that sensitive data is protected in transit.

4. Assign Appropriate Roles to Functions

With serverless, there can be many resources that must be handled, making management potentially complex. Creating minimal suitable roles for each function makes management easier, enhances security and reduces the attack surface of the serverless architecture. This approach means that the least privilege principle is applied, where a function only has the minimum permissions required to perform its intended task. It reduces the risk of unauthorized access to other parts of the infrastructure, such as sensitive data or other functions.

The right roles ensure that functions are isolated from each other and run in their own security context. This helps to prevent the spread of any security incidents, as well as ensure that the compromise of one function does not affect the security of the rest of the system.

5. Ensure Dependencies are Secure

It is common for serverless functions to have dependencies from various repositories like Maven and PyPI. These dependencies may contain known vulnerabilities which can be exploited by attackers. Securing application dependencies is important to prevent security incidents and ensure the reliability and availability of the serverless architecture.

This involves tracking and managing the dependencies used in the serverless applications. This helps to ensure that dependencies are used in a consistent and controlled manner, reducing the risk of conflicts or compatibility issues. By regularly monitoring and updating dependencies, organizations can ensure that their serverless architecture is secure and reliable.

6. Sanitize Inputs to Prevent Injection Attacks

Serverless applications often use data inputs from users or events. This data enables functions such as data streaming, but the user-supplied data can also pose security risks. Sanitizing event inputs helps to prevent injection attacks—these occur when an attacker injects malicious code or data into a serverless function through the event inputs.

By sanitizing inputs, organizations can remove or modify potentially malicious inputs, preventing the attacker from injecting malicious code into the function. One important form of sanitization is input validation—validating that the inputs conform to a specific format or type, such as checking that a string is a valid email address. This helps to prevent attackers from injecting malicious code into the function by ensuring that the inputs are in the expected format.

Sanitizing data is only one aspect of a defense-in-depth security strategy, which involves implementing multiple security controls to protect against attacks. It is also important to enable data escaping for SQL and noSQL databases. Likewise, the data provided by events shouldn’t be used to evaluate code at runtime or spawn system processes.

7. Secure Data in Transit

Securing and verifying data in transit helps to prevent data breaches and ensure the confidentiality, integrity, and privacy of data transmitted between different parts of the serverless architecture. Here are some guidelines for securing and verifying data in transit:
- Use HTTPS: This is a secure protocol for transmitting data over the internet. By using HTTPS, organizations can ensure that data transmitted between different parts of their serverless architecture is encrypted, preventing unauthorized access to sensitive data.
- Implement SSL certificate verification: Verify the identity of the certificate owner and the authenticity of the certificate. This helps to prevent man-in-the-middle attacks, where an attacker intercepts and alters data transmitted between the server and the client.
- Enable signed requests: These involve adding a digital signature to a request, which is then verified by the recipient. This helps to prevent tampering with data in transit and ensures the integrity of the data.
Conclusion

In conclusion, running serverless in production requires careful planning and execution to ensure the security and reliability of the architecture. By following the best practices described here, DevOps teams can reduce the risk of security incidents and ensure the reliability and availability of their serverless architecture. These include:
- Monitoring the serverless environment
- Implementing authentication
- Deploying API gateways
- Creating minimal suitable roles for each function
- Securing application dependencies
- Sanitizing event inputs
- Securing and verifying data in transit
Additionally, regularly monitoring and updating dependencies and implementing a defense-in-depth security strategy can help organizations ensure the security and reliability of their serverless architecture over time.
February 8, 2023
Massive Number of Transitive Dependencies Traced to Open Source Code

An analysis of nearly 2,000 software packages published by Endor Labs found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer used an open source component.

The study, conducted by the Station 9 research arm of Endor Labs, a provider of a platform for identifying software dependencies, concluded there’s still a 32% chance those software packages would have known vulnerabilities even after components are upgraded to the latest version.

Endor Labs CEO Varun Badhwar said vulnerabilities often remain because the last update made to one of those software components may have been made several years ago even though there are existing known vulnerabilities that affect it. Development teams can’t assume the latest version of a software component is secure, he added.

In general, functional dependencies are created whenever developers download a third-party component, he noted. The most important thing for any software development team to determine when assessing actual risk levels created by those dependences is determining how accessible any given vulnerability is to an attacker regardless of its severity score, noted Badhwar.

In the wake of a series of high-profile breaches, there has been an increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise. They often create patches for applications based on a list of potential vulnerabilities surfaced by cybersecurity teams. The issue, of course, is that just because there is a vulnerability it does not immediately follow that the affected software component can be externally accessed.

Endor Labs is making a case for a graph-based platform that identifies dependencies between the software components that make up an application environment. That approach makes it simpler to prioritize remediation efforts based on the impact a vulnerability might actually have and narrows the current divide between cybersecurity teams and application developers. By the time cybersecurity teams alert developers to a vulnerability they often have moved on to other projects. As a result, developers often lack context because it may have been months since they last looked at the impacted code.

Of course, the inclusion of DevSecOps best practices should improve the overall state of application security as more responsibility for it shifts left toward developers. However, achieving that goal will require more than just giving developers access to software composition analysis (SCA) tools that only surface vulnerabilities in source code as it is being developed, noted Badhwar.

In the meantime, the efforts to remediate all existing application vulnerabilities will be measured in years, so organizations need to determine where to focus their efforts. After all, every minute spent developing and deploying patches is less time that can be allocated to building and deploying new code. The trouble is that as more new code is written, the number of vulnerabilities that could be exploited increases and makes a bad situation worse.

December 12, 2022
Why App Dependency Mapping Is Critical for Cloud Migration
Software dependencies are a crucial part of efficient, component-based programming. At the same time, they can be a hurdle for fast-paced agile development teams, because they can make it more difficult to deploy, update and migrate software applications. Many applications have dozens or hundreds of dependencies, each with its own transitive dependencies, making the problem worse.

Dependencies are components that provide required functionality that a main component depends on. They can be incorporated into code using package managers like npm or Maven, Git-based code repositories like GitHub and container image registries like Docker Hub.

Application dependency mapping involves discovering and identifying dependencies and interactions between application components, their dependencies and underlying infrastructure. Creating a map of application dependencies is an essential part of gaining visibility over complex application structures and understanding the impact of deploying them in different environments.

Why Application Dependencies Are Critical for Cloud Migration

Application dependency mapping ensures you have identified all the components you must migrate to the cloud. You may not need to migrate all components to the cloud, but you do need to ensure all dependencies are identified and migrated together. Otherwise, your application may suffer performance issues because important dependencies remain on-premises.

For example, if you move an application server to the cloud but keep the application’s database on-premises, your application will experience severe performance degradation and may also cause related applications to fail. Once a dependency is disrupted, all related applications suffer. Therefore, when migrating applications to the cloud, you must include all associated dependencies.

How Application Dependency Mapping Tools Can Help

Application dependency mapping can help you avoid poor application performance and service outages. It is a critical component of the migration process, but is also difficult without automated tools. Application dependency mapping tools check an application and help with the following:
- Modeling all inter-server relationships
- Identifying inbound and outbound connection latency
- Determining the necessary TCP ports
- Detecting running processes
- Application performance monitoring over time
Cloud vendors offer specific application dependency mapping tools developed for their environments. For example, Amazon Web Services (AWS), Google Cloud and Microsoft Azure offer proprietary tools to help manage this process. However, these tools are tied to each provider, which means you should use the vendor tool that matches your chosen target cloud environment.

Alternatively, you can use open source tools that provide similar services but are vendor agnostic. Use these tools if you want an assessment that is not specific to a single cloud vendor environment.

Mapping Application Dependencies to Prepare for Cloud Migration

An application consists of a hierarchy of dependent APIs and tools. The hierarchy starts with the application’s interfaces and then goes down through platform tools. Dependency management helps identify combinations of related versions and ensures that the development team recognizes new application dependencies when changes occur.

Versioning application components

The first step in this process involves versioning application components. If you intend to deploy a specific software component independently, you need to assign a version number for every revision and then track the dependency chain for this version.

This technique ensures you know the specific platform tool versions associated with each application version. If you need to roll back, you know what additional components you need to roll back to ensure version compatibility.

Changing platform components

This technique requires changing some platform components, such as middleware, which also requires synchronizing each application’s platform version. You should start from the top of the application dependency chain.

Each application is designed to use specific operating system and middleware features, expecting “version Y or later” of the tools. As a result, you must validate each tool with a specified version against the tool’s dependencies and continue validating each of these dependencies until you reach the bottom of the dependency chain.

However, some application dependencies are not as obvious and explicit as others. You may encounter problems if you expect to run a guest operating system in a virtual machine (VM) on a hypervisor platform in a different source.

You may also encounter issues if a cloud stack release, like OpenStack, requires a certain scripting language version. You can mitigate this issue by testing every dependency chain against the standard middleware and operating system combination, ensuring that all dependencies are recognized.

Rebuild the dependency tree

Once you are ready to move to the cloud, you need to supplement the dependency tree for applications and include all the references to the cloud provider’s APIs and features. Make sure to determine how the provider notifies of changes to tools and APIs and prepare to validate new dependencies these changes can create.

For a multi-cloud or hybrid deployment, you must compare cloud dependency trees across all the components and applications planned to migrate beyond a cloud platform boundary. Note that having a different dependency tree for each provider can result in problems when scaling or failing over between providers’ platforms. You can avoid this by synchronizing components in advance.

You should also rebuild your dependency trees whenever you change software platform components. A basic update could undo all the mapping and work you have done, and you can easily overlook a change to a small middleware component. You can mitigate this by setting up a life cycle management process to ensure dependency problems do not arise when incompatible elements are introduced.

Conclusion

In this article, I explained the basics of application dependency mapping, and showed how application dependency tools can make cloud migrations safer and easier:
- Versioning application components—Understanding what version your application expects for all dependent components.
- Changing platform components—Determining the impact of switching out certain platform components.
- Rebuild the dependency tree—Use the map of your existing dependency tree to rebuild a matching dependency tree in the cloud environment.
I hope this will help you evaluate the use of dependency mapping and make your next migration a success.
August 3, 2022
Common Hidden Dependencies and How to Uncover Them
It’s no secret that a truly Agile approach minimizes the risk organizations assume with waterfall or other traditional project management methods, by letting teams iterate and inspect and adapt as they go. But many companies lack clear visibility into real-time dependencies at the team level—even with daily standups, iteration and release planning, and a regular cadence of cross-team check-ins. This lack of visibility impacts organizational agility and can erase the value of an investment in agile.

As Dwight D. Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” When it comes to planning within an enterprise, being aware of the biggest risks of hidden dependencies will help you keep a proactive approach and drive value from strategic objectives to tactical execution. Here are some of the risks of the most common dependencies and how to uncover them:
1. Teams that are distributed (or use multiple Agile platforms) do not have the flexibility to work across teams as easily as their co-located counterparts. This slows down response time, which in turn slows down releases. Teams must make dependencies transparent at the highest level to stress their importance. Make sure your team has an advocate, such as a Scrum Master, to raise red flags when dependencies or risks emerge.
2. Medium- and large-scale organizations may run multiple release planning sessions for one product. Running them at the same time, or in a sequence but in different locations, increases the risk that teams will overlap work and not plan for dependencies.
3. Many organizations and teams try to plan for dependencies by adding more time to their estimates as a buffer. While this seems like a good idea, it hides a problem by burying wait time and masking the real blocker. Organizations and teams should ensure that estimates are only based on complexity and effort and do not reflect “waste” such as wait time. Doing so helps reveal impediments for what they are.
4. In larger organizational structures, infrastructures are complex and teams tend to be highly dependent on one another delivering work, with a chain effect of one team’s work beginning only after another finishes. As they look to adopt and scale Agile, organizations should closely examine their structure to ensure it is optimized. This will reduce risks and dependencies, rather than exaggerate them.
5. Team members often allow “blockers” and “dependencies” to get in the way of completing work while still committing to a sprint or release goal. If team members foresee a dependency or blocker with key features, user stories, etc., they should not commit to the work. It is the responsibility of each individual to refrain from committing to work that they know they cannot complete.
Visualization is Key

Organizations can adequately manage dependencies and risks if they can plan for them. One helpful technique is to create a road map for releases. When consistently updated throughout at the end of each sprint, a road map helps teams identify risks and evaluate dependencies continuously. Selecting a platform that allows real-time visualization into dependencies is another way to prevent time-wasting while giving insight into the right details at the right time.

— Andrey Mihailenko
November 15, 2018
ADDI Addresses the Problem of Dependency Management

Want to know what a bad day looks like? Imagine you’re a developer working your way up the career ladder. One day your manager comes by your cube to tell you that you’ve been assigned to implement a critical, new feature in the company’s premiere application. You’re elated. At last you get to show off your coding mettle.

You spend the next two weeks working day and night to get the feature out. Finally, it’s time for release. You send out a pull request to merge your code into the codebase. Everything should be peachy. You can taste the stardom at hand. The next thing you know, your inbox starts to fill with emails complaining that your new code has broken the build. Turns out that the third-party libraries your code uses are older versions that have long since been deprecated. The code that works fine on your local system is causing havoc in the general codebase. Everything is going haywire. What should have been your hour of glory has turned into an episode of embarrassment and shame.

You Have Entered Dependency Hell

Anybody who has been coding for any amount of time has been in dependency hell. Those of us who programmed in early versions of Windows called it DLL Hell. Java developers have been burned by third-party .jar files that just don’t jibe as code moves down the release cycle. To this day, there is a legion of Python developers out there who are still struggling with the challenges of getting Python 2.7 code to work in newer Python 3 environments. Node developers face ongoing issues transitioning legacy code from ECMA 5 to ECMA 6. Dependency mismatch issues have been a problem throughout the history of software development. Mainframe developers have been blindsided by unknown dependencies since early batch jobs were run under JCL. Dependency mismatches are real and they hurt, sometimes too much.

So, What’s to Be Done?

The software industry has not been asleep at the wheel when it comes to solving the problem of dependency management. In fact, making dependency management easier—degrading it from likes of extreme dental pain to an addressable issue akin to an annoying muscle ache—has been a mostly successful undertaking.

One of the early goals of the .NET framework was to do away with DLL Hell. (DLL Hell is a corruption condition in DLL dependency referencing caused when COM objects declared in the Windows Registry are out of sync with the calling code.) .NET avoids the Registry altogether and references DLLs directly using the file system or the more easy-to-manage Global Assembly Cache (GAC).

Maven, a very popular Apache Project, brings a significant degree of order to dependency management for Java developers. Maven’s Project Object Model (POM) allows developers to declare exactly which version of .jar files their code needs to use. (See Figure 1.)

Figure 1: The Maven Framework for Java development allows projects to declare dependency versions

Babel allows Node developers to move between ECMA 6 and ECMA 5. 2to3 is a program that will convert code written in Python 2 to version 3.

Clearly, most programmers have confronted the issue of dependency management when developing new code. And, the industry has been active trying to lessen the burden of dependency management when introducing new code into an existing codebase. But addressing ways to management code dependency is not confined to PC-based computing; the mainframe community is actively addressing the issue, too.

Which Brings Us to Mainframes

The fact that code quality degrades of over time is not so much due to incompetent programming but rather the demands of continuous revision and the fast fixes put in place to meet the requirements of the moment. Sometimes down-and-dirty code that works today is preferable to more elegant approaches that will take months to implement.

In the mainframe world, there can be decades’ worth of these type of fast fixes in play. Trying to improve code can be a roll of the dice. Usually what gets broken is a dependency well beyond the immediate scope of programming activity. As mentioned earlier, dependency management has always been difficult. That’s the bad news. The good news is that the mainframe community is keenly aware of the problem dependency management and has done something about it. IBM’s solution, System Z’s Application Discovery and Delivery Intelligence (ADDI), is particularly adept at addressing the issue.

ADDI is a big product with a lot of features. One of the more interesting features is the Analysis Browser, which allows a mainframe developer to get a detailed understanding of all the dependencies in a particular application.

Figure 2: IBM Z ADDI Analysis Browser allows developers to visually understand code dependencies and program accordingly.

Having a clear, visual picture of all the dependencies in mainframe application is a very big deal. Mainframe code is by nature onerous. There are a lot of parts that are hidden due to the immensity of the technology. Using human intelligence to try to figure out all the dependencies in force takes too much time. Hence, a tool such as Analysis Browser is indispensable when it comes to addressing the age-old problem of dependency management.

We’re All in This Together

In the past, identifying dependency problems usually resulted in someone getting woken at 3 a.m. to fix a mission-critical problem. Using a proactive tool such as ADDI’s Analysis Browser allows more people to get a lot more sleep. Comprehensive dependency management does not need to be the result of ongoing catastrophes in production; rather, quite the opposite.

The first step to reducing the risks and calamities caused by dependency misalignments in code is to make a commitment to address the problem. The world of software development is littered with teams who just want to get through the current release and are more than happy to repeat the insanity dependency hell all over again in the next one. The excuses vary from, “We don’t have the time to do a solution,” to, “It may not be the best way to do it, but I’ll always have a job.”

Once a commitment is made, then it’s a matter for tools and process. You use the tools to determine risky dependencies. You follow process to improve the release.

Whether you’re in a distributed shop that embraces ephemeral, on-demand provisioning or a more mature mainframe shop working with Big Iron, the fact is that reliable dependency management is critical for the well-being of the enterprise. Yes, while it’s true that the details of coding and code management will vary from an IBM Z to an AWS cloud instance, the underlying thinking that brings good dependency management together is strikingly similar. As just mentioned, it’s a matter of tools and processes.

In terms of implementing ways of dependency management that work, we might be speaking different languages. But, when you take a close look at the basic concepts behind effective dependency management, you’ll find we’re all saying the same thing.

— Bob Reselman

April 12, 2018