Forem: Daniel Parmenvik

Supercharged Dependency Management With A Dependency Firewall

Daniel Parmenvik — Fri, 26 May 2023 13:11:26 +0000

Hey devs,

Thought I'd share a new way to manage dependencies securely.

Why a Dependency Firewall?

In our increasingly connected world, your applications are only as secure as your most vulnerable dependency. This is where a Dependency Firewall comes in. It guards your projects and organization against insecure or malicious packages.

How? Not only does it protect your software from known vulnerabilities, but it also blocks packages that could compromise your environments by putting them in Quarantine based on your configured set of policies.

Here's the kicker: Bytesafe Community Edition isn't just an effective package repository; it's also boosted with a built-in Dependency Firewall where you are in control of the knobs.

Bytesafe is a high-performing alternative that can handle npm, Maven, Python (pypi), and NuGet packages.

You're probably comfortable with your current setup using Verdaccio or Nexus Repository OSS. But what if you could step it up a notch?

Let's explore some of the reasons you might want to try Bytesafe out or make a switch:

1. Advanced Security

Bytesafe puts a strong emphasis on security (and not only package management). It has a built-in feature that detects vulnerabilities in your dependencies. Moreover, it introduces the concept of a Dependency Firewall to block malicious packages based on the policies you configure.

I know you've read all about the increasing number of attacks and that they are becoming more sophisticated, how post-install scripts can install pretty much anything etc. - so you can never be too careful. Bytesafe helps you sleep better.

2. Powerful and Free

The Community Edition is absolutely free. You get the robust features and capabilities of a top-tier solution, without burning a hole in your pocket. Yes there are limitations compared to the commercial alternative, but for small teams it rocks! Look at this feature comparison to see the differences.

3. Easily Installable

Bytesafe can be easily downloaded and installed via Docker or Kubernetes, making it an excellent choice for devs operating in diverse environments.

Getting Started with Bytesafe - Download & Install

To get started with Bytesafe, head over to the Official Github Repository.

For more in-depth guidance on how to set up and use Bytesafe, refer to the Official Documentation.

For npm enthusiasts, you can follow the Bytesafe and npm guide. Pythonistas can refer to the Bytesafe and Python guide.

Bytesafe Community Edition is a game changer for small teams in dependency management. Its advanced features, emphasis on security and being able to control workflows, and ease of installation make it a compelling alternative to existing tools.

So, why not give Bytesafe a try and let us know your thoughts? Feedback or have any issues, create issues in the Official Github Repository

Happy coding!

If you found this article helpful, be sure to leave a 👍, comment and share it with your friends. And help spread the word!

Protect Your System from Install Scripts in npm packages

Daniel Parmenvik — Fri, 13 Jan 2023 14:40:25 +0000

Fellow developers, utilizing open source dependencies in your projects can bring many benefits, but it's important to be aware of the potential dangers as well. One hidden risk to watch out for are Install Scripts.

Install scripts are scripts that run automatically when a dependency is installed and can be used for tasks such as transpiling source code and fetching remote resources. However, they can also be used to execute malicious code on your system, potentially stealing data, encrypting files for ransom, or launching other attacks.

Using install scripts is a common method for spreading malware via npm packages, so it's essential to take extra precautions to protect yourself from malicious install scripts.

Blocking Install Scripts to avoid malware

Although it's possible to disable install scripts in package managers like npm, they by default automatically execute Install scripts automatically by default.

Option 1 - do it manually

One way to block install scripts and avoid malware is to disable them manually by using npm install --ignore-scripts. However, this may be a challenge to enforce for an entire company or across all environments.

Option 2 - automatic enforcement for an entire company

Another option is to use a Dependency Firewall, such as Bytesafe, which allows you to quarantine unwanted open source packages with vulnerabilities or non-compliant licenses. The platform provides a policy engine where you define the open source usage and security rules and the Dependency Firewall does the enforcement.

The security policy Block Install Scripts for npm firewalls and registries can block all npm packages with pre- and post-install scripts, allowing you to use packages with confidence knowing they have been reviewed for potential security risks.

Keep in mind, packages may depend on install scripts, so some initial review work may be required.

Create a free private Maven repository with Bytesafe

Daniel Parmenvik — Wed, 26 Jan 2022 08:37:49 +0000

Working with any of Maven or Gradle in your Java, Kotlin and Scala applications?

Recently heard of any supply chain attacks, account takeovers or malicious dependencies? Yeah, almost daily...

It's more important than ever to keep track of your software composition and the risks you're exposed to. And better yet - stay in control of your dependencies with a private registry and stay secure.

Continue reading to add security to your supply chain using Bytesafe and stay in control of what dependencies you use.

By the way, creating a hosted private Maven repository is FREE!

Why use a private repository?

There are many benefits of using a private regisrtry. For example, using a private registry is the right way to go if you want to lower your business risk and:

Want a central hub to host all your dependencies - private and public ones.
Continuously want to monitor packages for vulnerabilities or license issues.
Require a dependency firewall that can control and block unwanted packages from entering your supply chain.

A private and hosted repository allows you to focus on your code and can get started without having to think of and plan for infrastructure, capacity management, maintenance etc.

How to set up a private repository with minimal effort?

Great! You’ve decided you need a private repository and want to get going.

These steps will let you get your own private repository using Bytesafe:

1. Create a Bytesafe Workspace

First create your own workspace by signing up.

Just select the workspace name that you would like to use.

When you have created your account you can access your workspace by using the workspace name you’ve just create: https://<workspace>.bytesafe.dev

2. Sign in to your Workspace

Use your GitHub, Google, Microsoft login or sign in using email and password.

Congratulations! You now have access to your first private repository called "default". It's ready to be used. You can also create more registries with support for other ecosystems (npm, nuget) - quick and easy!

If your organization prefers integrating using SAML for Single Sign-On, that is supported too.

3. Configure Maven to use Bytesafe as a Proxy

Bytesafe private Maven registries allow users to both deploy internal Maven artifacts and proxy public packages from Maven repositories.

A single source for all Maven compatible packages required by your teams and CI/CD pipelines.

Configuration details are described here, but the simple steps you need to take are:

Create and add an access token to your settings.xml
Point out your Bytesafe Maven repository (settings.xml / pom.xml)
Now continue to use Maven or Gradle like you're used to - but with the benefit of having Bytesafe as your Dependency Firewall with secure dependencies.

What's a Dependency Firewall for Maven packages?

The Bytesafe Dependency Firewall works with different package types, including Maven packages. The Dependency Firewall adds significant security to an organization’s supply chain while at the same time being transparent and easy to use for developers.

All new registries have Vulnerability Scanner and License Compliance enabled by default. Users can enable automatic quarantine of serious threats, preventing them from compromising your organization.

Want to protect developers and automated environments from unintentionally adding newly released (and potentially malicious) dependencies? Customize the safety delays for your repository, allowing new versions to mature and be vetted by the community before use.

That's it!

You have just added a layer of security with your first hosted private repository where packages are continuously scanned for vulnerabilities and license issues. Hope you'll enjoy your private registries!

From here you can create more registries, enable plugins and policies to get the right level of control that you require and optionally you can invite new team members which is a premium feature (as you'll have free trial of the Teams plan).

Have any questions or suggestions on features that you would like to see? Comment below or contact us on Twitter @bytesafedev.

How to avoid Software Supply Chain Attacks

Daniel Parmenvik — Wed, 17 Nov 2021 10:19:31 +0000

Cybersecurity attacks only continue to increase and in 2021, supply chain attacks are expected to grow by 400% according to the report ENISA Threat Landscape for Supply Chain Attacks. Security minded companies are quickly making supply chain security a main focal point - but the software supply chain is still considered the weakest link by threat actors.

The increase is well in-line with how often we read about new ransomware and malware attacks. Just recently there were account takeovers on the popular packages ua-parser-js, coa and rc with a combined average of 30 million weekly downloads.

If your organization is exposed to a malicious version, a compromised system means anything would be possible for attackers - installing backdoors, crypto miners, keyloggers and extraction of data. All bad and increasingly public, causing substantial monetary and reputational loss. Don’t think that JavaScript/npm is unique in this regard - the same problems exist in other ecosystems like Maven, Nuget and Python.

One single bad dependency, out of the probably hundreds or even thousands of dependencies you are using, can put your whole business at risk. Failure to protect the supply chain is not an acceptable option.

Even though the metrics are not the most uplifting, the great news is that with proper supply chain security you can mitigate threats and protect your organization. Stop the lurking big fish before it’s too late!

This article will guide you through the difference between an insecure and secure supply chain setup to prevent supply chain attacks.

Why are supply chains so insecure?

With ecosystems like npm it’s so easy to get caught in the dependency trap using external code for everything - even when in some cases components are one-liners. The more dependencies you use, the higher is your inherited risk. And from an attacker’s perspective it’s the more the merrier - as you’ll have more risk exposure.

The reason why many organizations’ supply chains are considered insecure is the fact that Developers and CI/CD (build environments) have unfiltered access to the full universe of dependencies - directly from external sources.

If your development pipeline is similar to this, you should pay extra attention to this article. Don’t worry, you are not alone and reading this article is a great first step.

When developers and CI/CD are able to install components directly from external sources there are no safeguards to protect you from malicious versions or vulnerabilities.

Even though you benefit from rapid and creative development, you have no way of enforcing policies and controlling what dependencies are used in your organization. If you’re interested in reading up on the security risks related to the large dependencies trees, check out this article.

How to avoid “Oops, we’ve had a security breach”

Waking up and realizing that you’ve been compromised is a nightmare. And knowing it could’ve been prevented doesn’t help in afterthought. The fundamental thing to do is to adopt a secure software supply chain and protect your organization - now, before it’s too late.

A secure software supply chain is about knowing what dependencies you’re using, keeping them secure and to be able to control workflows - across every developer workstation and automated environment within the organization. This includes an end-to-end security approach and enforcing the business policies you’ve decided at every step.

Steps to secure your supply chain

We fully recognize that for many companies security is a journey, and knowing where to best get started can be a difficult decision and a barrier to properly addressing issues.

To help out, we’ve compiled a shortlist of security steps to take your organization from basic protection to the maximum protection of the full Bytesafe Dependency Firewall.

Basic - Protect your organization with a central dependency source

Make sure every piece of your supply chain is sourcing data from a centralized internal source that you have control over, with known and allowed components.

Remove direct links to unsecured dependency sources or else you run the risk of installing compromised and vulnerable dependencies.

Medium - Scan, identify and remediate issues

Identifying issues early, reduces risk exposure and also saves both time and money. Continuously monitor the dependencies in your supply chain for security and license compliance issues.

It’s important to use up to date and secure components, but patches should be applied intelligently and not instantly to avoid zero-day attacks.

Advanced - Protect and Block

Enforce your business policies. Set up policies to do the work for you and shift responsibility from individual-level to company-level.

Protect internal packages from attacks like Dependency Confusion.

Unifying everyone under the same level of protection (avoiding misconfiguration, which is a common source for attacks).

Maximum - Control workflows & verify deployed applications

When improving cybersecurity protection, maximum protection includes being able to control workflows, check components for security and compliance issues and to verify the actual deployed applications.

Bytesafe Dependency Firewall will automatically quarantine unwanted packages so that they will be isolated from use in your organization. Like a chain supply guard, Bytesafe won’t let your organization use the unwanted packages.

JavaScript dependencies are often bundled in your CI/CD environment, but dependencies can also be included in web applications using the <script> tag.

Checking what has actually been deployed to production is a necessity for end-to-end security and for maximum protection.

Be sure that you are able to freeze the universe and versions of dependencies you are using and that your registries/repositories you’re using can be adapted to your agile process - regardless if you have daily, sprint releases or monthly releases.

Thanks for reading!

Crap, we might have installed a malicious dependency...

Daniel Parmenvik — Fri, 29 Oct 2021 10:24:01 +0000

That was the reality for a lot of companies after the ua-parser-js supply chain attack. On October 22 three malicious versions of the popular package ua-parser-js were released. A package which has almost 8M weekly downloads. If your company has used compromised versions of this package directly or indirectly, consider your system as fully compromised.

So you might think how the heck is this even possible? After all, “it’s just JavaScript”?

The maintainer account for ua-parser-js was taken over, meaning attackers had control and deployed malware versions. These versions in turn were downloaded by many users around the world. Silently the malicious versions installed a trojan and a crypto mining application.

The impact is critical with the file system made public, screenshots taken as well as downloading and execution of unknown binaries.

The result

A lot of companies are still vigorously trying to figure out if they were exposed. Often by spending resources and money on manually making sure no one inside their organization used the affected malicious versions.

I fully understand the need for companies to be sure they’re not affected - but this problem also indicates that companies lack proper control over external dependencies. An investment into proper protection is something that would save money in the long run.

TL;DR

Malicious and packages with vulnerabilities. You need to protect you team, environments and organization without depending on specific individuals when it comes to dependency security. Here's a free downloadable checklist (PDF) .

How could this happen?

The component ua-parser-js is used to detect browser user data and is used indirectly by many others. For example the popular web ui framework angular.js has a dependency to test framework karma which in turn has a dependency to ua-parser-js. This is commonplace in JavaScript where applications on average depend on up to 700 other components - and most of these are indirect.

As you know, to be able to use a JavaScript app, you need to install its dependencies first. Something which is very easy, but where things can go really wrong. If the packages you’re installing, or any of the indirect dependencies, contain vulnerabilities, then you might be out of luck.

It’s crucial to secure your whole software supply chain, including software build environments (CI/CD), test, development and similar.

The problem lies in that a lot of environments are not restricted in what packages can be downloaded and installed. And with as little as 10% of all maintainers using two-factor authentication, the companies need to take dependency security as a serious threat and act accordingly.

So, what's the solution?

Quite a few people have contacted us asking how this could have been prevented and how to stay secure.

1. You need automated tooling where you are able to secure your existing workflows. This way developers and systems are secured by default. Unfortunately, many companies fail in this regard which is a major gamble. It works until it no longer does.

2. Companies need to enforce dependency policies and make sure they have the right tools to be able to control what packages are allowed in the organization. Make sure neither automated systems nor developers install the latest versions of packages without first taking a conscious decision. Avoiding outdated and vulnerable components is of course not an option either!

3. Companies need tooling to keep track of what components are used and where. Manually reviewing every piece of software or line of code is neither efficient nor possible in many cases when an incident occurs. Be proactive and secure your supply chain before it’s an emergency.

Download a checklist on dependency security

We are in the final sprint of the Cybersecurity Awareness Month - so why not spread some awareness 😊. Here's a one page cheat sheet on what measures you can take to protect your organization, link to blog post with a free downloadable PDF.

Block npm package threats using a dependency firewall

Daniel Parmenvik — Tue, 24 Aug 2021 12:39:48 +0000

If you've ever installed an npm package to JavaScript projects you doubtlessly have seen the status messages with a list of known vulnerabilities in the terminal output.

With npm, yarn or pnpm providing basic vulnerability information during package installation, it's hard to ignore how frequent vulnerabilities have become. That’s great service and security measure for the millions of daily users that rely on these tools for their projects.

added 57 packages and audited 3 packages in 107 s
2 critical severity vulnerabilities

But what if you want to block threats before they even enter your supply chain? Maybe you prefer getting automatic notifications with critical issues instead of checking manually? Or, would like to avoid potential security risks that may be critical for certain environments?

And what happens when it's no longer a developer installing dependencies, but rather an automated environment? A key component of modern security tooling is to make sure threats are actively blocked, and you are notified of issues, even if no human is actively monitoring it.

Below I will introduce you to how to quarantine problematic packages using the dependency firewall in Bytesafe.

Whenever a critical vulnerability is detected you might want to take immediate actions so that your teams, environments and business are protected - so your software supply chain can remain secure. Go ahead to learn how to quarantine unwanted packages from entering your supply chain!

Quarantine in short

Quarantine allows you to automatically block the use of specific packages that surpass security threshold levels, for example npm packages with serious identified vulnerabilities. While simultaneously highlighting the issue for your teams to address instead of blocking (and hiding) them.

This means that you’ll get a powerful tool to control allowed packages for all developers & systems while being very easy to use.

Why use automatic quarantine of problematic packages?

Secure usage of open source software is a necessity for modern organizations with cyber attacks becoming more and more of a common occurrence. And it's more than just an IT problem, with consequences that can potentially impact the whole organization.

At the same time every development team is required to balance productivity with security needs. So security solutions need to protect you while still allowing you to be productive.

Modern security problems require modern tooling. Efficient tooling that highlights potential issues while working within your regular workflow. Tooling like Bytesafe that continuously monitors your packages for issues and helps you stay secure.

Benefits of automatic quarantine of vulnerable packages

Prevent malicious threats with a firewall for your supply chain. Quarantine packages according to your security thresholds. Automatically block the use of known vulnerable packages - while still securely holding the vulnerable version inside your Bytesafe workspace for you to address.
Highlight security issues for remediation. Quarantine offers significant advantages to simply blocking packages outright. When a package is held securely within Bytesafe an issue will be created that notifies you of the problem. Allowing your team to easily and quickly remediate any issue and proceed with building awesome applications.
Avoid getting overwhelmed with issues - configure your thresholds & rules. Reducing noise to a manageable level is critical for any team. Otherwise notifications of security issues will simply get ignored. With Bytesafe you can customize at what severity level you want packages to be quarantined. You can also decide to avoid quarantine for issues without patch versions solutions available - all to allow you to work efficiently with your supply chain security.

Areas in the development life cycle (test, builds, deploys etc) are increasingly being automated with minimum human interaction. Make sure to keep up and manage open source dependencies securely with the appropriate level of detection and protection from vulnerabilities.

Configurable security thresholds according to your business needs

The Vulnerability and License scanners allow you to define when you want to pull the handbrake and immediately throw a package in quarantine.

The vulnerable open source packages will be blocked from being used in your supply chain. This way you are effectively using Bytesafe as a firewall as a quarantined packaged cannot be used from the Bytesafe registry.

The plugin settings contain additional configuration for when you want a package to be quarantined. When the quarantine feature has been enabled, the default threshold is set to High. This means that packages with a severity level higher or equal to High will be placed in quarantine.

You can also configure to only quarantine packages if they have patch versions available, typically used when you want to be notified of problems but decide you want to continue your work without breaking any builds.

Visit Bytesafe documentation to learn more on how to configure quarantine for your needs.

Release a package from quarantine

In situations where you have evaluated the risks with a quarantined package and made an assessment to approve the use package you can easily release packages.

Releasing from the quarantine area means the package version will be flagged as safe to use. The package will be accessible from Bytesafe by all developers and environments.

The activity log of any issues related to this package will also show that the package has been released from the quarantine.

Want to read more on how to control your software supply chain?

Stay up to date with other security related posts that might interest you:

How to use a secure by default solution for dependency confusion

Automatic protection from dependency confusion

Andreas Sommarström ・ May 19 '21

#npm #security #javascript #node

How issue tracking across your registries helps you get an overview of what needs your attention

Track issues from problematic npm packages

Daniel Parmenvik ・ Aug 24 '21

#javascript #npm #devops #webdev

Track issues from problematic npm packages

Daniel Parmenvik — Tue, 24 Aug 2021 07:03:30 +0000

Regardless if you’re working as a developer for a small startup or a global enterprise - you’re up to the same challenge. You’re dependent on open source npm packages outside your control and you need a way to keep track of problems that arise.

Unfortunately the state of open source software is frequently changing 😫. Problematic versions are detected all the time, so there’s never a guarantee that the components you’re using today won’t cause any problems in the future. It’s like a stream of problems that pop up and require you attention.

This post describes how you can use the workflow in Bytesafe to keep track of detected problems in your private npm registries as well as what has been remediated.

Let's move on!

Access to the REAL truth by tracking issues across all registries

As you know, applications having hundreds of dependencies is a typical scenario. Keeping track of all problems that arise can be a challenge for any company and especially if you don’t have a structured process in place. Only scanning registries once in a while or periodically looking for new vulnerabilities or license compliance issues is not a sustainable solution to stay secure.

So what you probably want is an automated workflow where you get a good overview of all problems, right?

Why is this good?

Normally you only see known issues during package installation when using an npm client (npm, yarn, pnpm), but future problems are not detected unless you use another tool that allows tracking of problems and that notifies you when new problems are detected. Using Bytesafe, you get access to the real truth = the state of your registries. If you are currently not monitoring your packages and issues, then you’re being blind-folded for problems like new vulnerabilities that might impact your security.

The plugins and policies in Bytesafe continuously monitor actions made to your registries and scan your existing packages for potential problems. If anything is detected, issues will immediately be created for you, notifications will be sent out and from there the workflow is straight forward. This saves time which instead can be used to remediate issues!

The overview of issues can be filtered and if you prefer to search for a specific issue that is available as well.

Read more about Issue tracking

Issue metrics in the dashboards

The Bytesafe dashboards show metrics with detected issues grouped by severity level. The metrics are linked and give quick access to the issues filtered depending on what metric you clicked on.

Track the remediation of open issues

Keeping your open source libraries up to date is key. Issues in Bytesafe contain relevant information on why an issue was created and notify you when something needs your attention.

Each issue is uniquely identified with a numeric identifier so that it is easy to refer to and share with others. All issues have a type, title, description, status and severity. If you decide to change severity levels, titles or descriptions you can do that by changing the values or editing the text.

Issues can be linked by referring to other issue IDs in comments. Bytesafe also keeps track of similar issues, for example other issues caused by the same security advisory in different registries.

Anyone interested in getting notifications for a particular issue can just add themselves as a watcher and stay updated.

Track changes in the Activity log

From an audit point of view, development teams are expected to know when packages were added to a registry, when issues were detected, what apps were impacted and finally when the issues were remediated.

Bytesafe helps by tracking all updates and changes to package versions in the Activity log where it is easy to follow what actions have been made. This is often requested information by organizations that require traceability, such as regulated businesses.

Now you’ll quickly be able to give incident managers, risk officers, auditors and other stakeholders a fast response - no more digging in logs or similar.

All issues are shown as clickable badges on the package card as seen in the examples below.

Read more about Issue tracking

Being exposed to risks such as vulnerabilities and license compliance issues is inevitable when using open source components. That’s why we need proper tooling to help us keep track of issue remediation and to reduce risk exposure.

Hope you’ve learned how a tool like Bytesafe can help you in this regard.

Cheers! 👍

Don’t upgrade your npm package versions by accident

Daniel Parmenvik — Mon, 28 Jun 2021 13:06:27 +0000

Looking for ways to make sure that your deployments to different environments are identical and use the exact same package versions? Or does your company have requirements to be able to reproduce deployments and trace exactly what dependencies were used at a specific time? Great - continue reading!

Being dependent on open source 📦 npm packages means dependencies to the public npm registry and npm package maintainers = constantly changing environment. This also means that you have the responsibility to keep track of what package versions were used in a specific deployment. This is a crucial task to reduce risks and make sure unintended changes have not been made.

Even without any change to package.json your builds may produce a different set of dependencies at different points in time (semver versioning and addition of new minor versions to public registries).

The slightest change in patch versions means your builds are no longer deterministic where you are guaranteed the exact same results - and deploying dependencies that have not been tested is never a good idea...

So what's the solution?

💡 For me, the way to go is to freeze your registry when you want to avoid accidental updates. Freezing a registry effectively locks down the state of your package versions and makes the registry read-only so that only intended changes are applied to code you trust.

The video below shows the easiest way to make your registry read-only using the Freeze policy in Bytesafe:

Benefits of using the Freeze policy in Bytesafe:

✅ Guaranteed exact same versions when testing and building your applications

✅ Deterministic and consistent results across all your environments such as Test, UAT and Production

🔗 This blog post also describes how to work with the Freeze policy to achieve consistent tests and builds.

What's your solution to this issue?

I would love to hear what you think of this solution and how you avoid accidental updates today. I'd be happy to answer any questions you might have.

What are your top things you love ❤️ & hate 💔 about the npm ecosystem?

Daniel Parmenvik — Tue, 22 Jun 2021 09:41:26 +0000

Node Package Manager (npm) helps us a lot in terms of performance when building new awesome applications - so many packages available and ready to be used. But over time there are also a lot of things you wished could have been better...

So, what are the things you love, hate, miss, wished could be better when using the npm ecosystem?

Write down your top thing!

Apply rules and automations to your npm registries

Daniel Parmenvik — Thu, 17 Jun 2021 10:03:49 +0000

Most developers would rather be coding than spend time managing dependencies. To keep up with the fast releases proper tooling is a necessity.

Manually monitoring dependencies for known vulnerabilities is both a time sink and a liability. Performing point-in-time checks will eventually mean you regret why you didn't do it automatically.

Spending time making sure that all teams and systems only use the same approved dependencies, across different environments, is also neither productive or fun.

Managing dependencies securely and efficiently involves the need of a tool that offloads some of the work for you. So you can focus on other things - and avoid human error.

Watch this video to learn how Plugins and Policies in Bytesafe let you apply business rules and automations for your secure private npm registries - so you don't have to.

🧑‍💻 Sit back, relax and let Byteasafe's plugins & policies do the work for you.

🔍 Here are just a few use cases:

✅ Lock versions for a registry with Freeze - making sure every user gets the exact same versions from the registry that you used for development - A powerful way to lock dependencies after development is completed, before passing it to QA/Testing or build systems.

✅ Block specific packages or packages with known vulnerabilities

✅ Auto increment package versions on publish to the registry - so you don’t have to manually step the version before every publish

✅ Auto forward package versions to linked upstream registries. Storing maintainer tokens securely in Bytesafe + using Forward plugins removes the need to share maintainer tokens (and avoid security risks).

There is more to discover! Give Bytesafe a try.

Introduction to open source security in the supply chain e-book

Daniel Parmenvik — Thu, 10 Jun 2021 12:59:10 +0000

Would you like to better understand what it means for your business to use open source npm packages and need a good summer read? 📖 🌞

It’s a simple fact that open source is everywhere and we all seem to have a never ending thirst for more of them.

So, questions do need to be raised on what controls are in place for the open source components your team are using. To aid that discussion we have just published an e-book called Don’t be the weakest link in your software supply chain.

📘 Book chapters

The book contains everything you need to know about controlling the open source code your business depends on, identifying the risks of the software supply chain and how to effectively manage them.

🚀 Bytesafe

Bytesafe reduces the risk of businesses failing to keep track of components, their dependencies and open source licenses.

The Bytesafe team has extensive first-hand experience on the challenges companies face in highly regulated businesses when managing and deploying open source code.

If you have any questions or feedback - just drop me a message. I would love to hear from you!

Download our free e-book

How to use secure private npm registries

Daniel Parmenvik — Thu, 10 Jun 2021 12:57:25 +0000

Working with open source npm packages is so fast and easy that security and control is often pushed to the infamous "some other time" - or simply neglected.

But why? There are solutions that add security with almost no effort and without impacting developer performance! Watch the video below to see how easy it is.

Risks associated with using open source npm packages should not be overseen and the number of threats in the ecosystem only increases (like the much discussed dependency confusion). Not to mention that the potential impact on your business is catastrophic.

To take back control you should look into adding a private npm registry into your supply chain. And working with a private registry does not even have to impact your workflow. Simply configure the registry and use the private registry instead of using registry.npmjs.org directly.

Here's a video that shows you just how easy it is to work with secure private registries that are secure by default.

What is Bytesafe?

Want to block or quarantine packages that contain vulnerabilities? Need to make sure that your apps don’t depend on code that doesn't fulfill your business policies? Or maybe you’re looking for hosted secure private registries to be able to share packages and collaborate?

"Inga problem", as we say in Swedish = Not a problem.

Bytesafe is a devtool that makes life easier to trust code you are dependant on by:

Controlling what packages and dependencies are being used in applications and securing workflows for both internal and external packages
Knowing what security and open source license issues exist in the code you depend on so that they can be remediated
Protecting the business from unintended packages entering the software development lifecycle (dependency confusion) - working like a dependency firewall