Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

How to address security in white label software

mozzy

Coder
I just started working with a business that made a web application that has a nodejs-expressjs backend api and a react front end. The business wants to sell its software as a white label solution to some enterprise sized businesses. My manager says that the customers will be expecting a detailed report to convince them that our solution is "secure". I need to determine steps to producing such a security report.
My first thoughts are to follow these steps:
  1. Run the npm audit command on our backend and front end projects to identify all known vulnerabilities. And then fixed them according to recommended approaches I read about on the internet. This step has been done. The npm audit command shows no vulnerabilities or issues of any kind.
  2. We upload our code as docker images to dockerhub.com. Dockerhub shows a list of vulnerabilities for us to address. I am currently in this step, and I have some issues which I will elaborate further down in this post.
  3. Hire a 3rd party cyber security firm to test our solution. This firm will give us a report of issues to address.
That's my overall plan. However, I am currently stuck on step 2. Dockerhub is showing me MANY Critical and High priority vulnerabilities such as the following:
  • cve-2021-44906 - An Uncontrolled Resource Consumption flaw was found in minimist
    cve-details
  • CVE-2022-37434 - zlib through 1.2.12 has a heap-based buffer over-read or buffer overflow in inflate in inflate.c via a large gzip header extra field.
    NVD - CVE-2022-37434
...etc...
According to dockerhub, there are about 100 of these types of vulnerabilities, where maybe 10% are critical, 15% are high, rest are medium or low. These issues look very difficult to address, because they are used by modules of modules that I don't directly access in my own software. Trying to replace these modules of modules basically means a complete rewrite of our software to not depend on ANY open source solutions at all! And I'm sure if I were to scan packages with another type of scanner, different sets of vulnerabilities would be exposed. And I haven't even gotten to step 3 yet.

So this got me wondering...how do other organizations selling white labelled solutions go about disclosing vulnerabilities to their end clients and how do they protect themselves?
I started thinking that maybe I don't have to deal with every single security vulnerability that exists. Instead, I should only address security issues that I am confident hackers will exploit or things that are easy to address. Then I hire a security party firm to find other vulnerabilities. Anything that's not caught by the security firm we deem as "not important". And we develop some contract and service agreement that protects our business from the legal actions if our clients experiences a security vulnerability not covered in our report?

But then, a customer will say, "But dockerhub.com clearly shows vulnerability X, and you as the seller were aware of vulnerability X, please justify to us why you did not address it." And how do we respond then?

That's what's in my head right now.

So back to my original question - what steps should a team take to address security concerns of a software that will be white labelled and sold to customers?
 
Last edited:
Hey there,

You've already embarked on the heroic journey of security-hardening your application, and from what you've described, it looks like you're not just dipping your toes but are ready to plunge into the cybersecurity deep end.

Running npm audit was like the first lap in the security Olympics — essential, but there's more to the marathon. It's great that your security pool is free of the known sharks, but those Docker vulnerabilities you've uncovered sound like a school of piranhas waiting to nibble away at your code's integrity.

The Dockerhub dilemma you're facing is a common one. Those critical and high priority flags waving at you are not just for show, they're red for a reason. But let's put on our cyber snorkels here and take a deep breath. We're not going to rebuild the entire ship to avoid a few leaks — instead, we focus on patching up what's necessary.

You're spot on thinking about third-party cybersecurity firms; they're like the lifeguards who can dive deeper to rescue your code from potential threats. They'll not only identify the vulnerabilities but also give you the lifesaver in the form of a robust report.

Addressing vulnerabilities is a bit like playing Whack-a-Mole; you fix one, and another pops up. You're right in thinking you can't tackle every single one. But here's the kicker — it's all about risk management. It's not about fixing all the vulnerabilities; it's about fixing the right ones.

And when it comes to justifying why you didn't put a life jacket on every potential code vulnerability, it's all about the risk profile. If a vulnerability requires such specific conditions to exploit that it's virtually impossible in your application's environment, then that's your answer. It's about choosing your battles wisely.

Now, in the scenario where a client points out a vulnerability you chose to accept the risk on, you'll need a narrative. Explain how your application architecture, other security measures, and monitoring make that vulnerability as threatening as a rubber duck in the ocean — not entirely harmless, but under constant supervision.

Crafting a contract to protect your ship from potential storms is crucial. This isn't a treasure map where 'X' marks the spot for unlimited liability. Define the terms clearly, ensure there's a mutual understanding of maintenance and updates, and that everyone knows the protocol if a cyber kraken does emerge from the depths.

So, how do you chart the course from here? You've got your map:

  1. Inventory your arsenal.
  2. Prioritize the threats — not all pirates are after your booty.
  3. Engage with the cybersecurity coast guard.
  4. Communicate with your crew and passengers.
  5. Document the voyage.
  6. Draft the code of the sea.
  7. Keep a lookout for new threats.
Remember, you're not in a dinghy; you're captaining a robust vessel. It's all about sailing smart and staying vigilant.

Fair winds on your journey!
 
I just started working with a business that made a web application that has a nodejs-expressjs backend api and a react front end. The business wants to sell its software as a white label solution to some enterprise sized businesses. My manager says that the customers will be expecting a detailed report to convince them that our solution is "secure". I need to determine steps to producing such a security report.
My first thoughts are to follow these steps:
  1. Run the npm audit command on our backend and front end projects to identify all known vulnerabilities. And then fixed them according to recommended approaches I read about on the internet. This step has been done. The npm audit command shows no vulnerabilities or issues of any kind.
  2. We upload our code as docker images to dockerhub.com. Dockerhub shows a list of vulnerabilities for us to address. I am currently in this step, and I have some issues which I will elaborate further down in this post.
  3. Hire a 3rd party cyber security firm to test our solution. This firm will give us a report of issues to address.
That's my overall plan. However, I am currently stuck on step 2. Dockerhub is showing me MANY Critical and High priority vulnerabilities such as the following:
  • cve-2021-44906 - An Uncontrolled Resource Consumption flaw was found in minimist
    cve-details
  • CVE-2022-37434 - zlib through 1.2.12 has a heap-based buffer over-read or buffer overflow in inflate in inflate.c via a large gzip header extra field.
    NVD - CVE-2022-37434
...etc...
According to dockerhub, there are about 100 of these types of vulnerabilities, where maybe 10% are critical, 15% are high, rest are medium or low. These issues look very difficult to address, because they are used by modules of modules that I don't directly access in my own software. Trying to replace these modules of modules basically means a complete rewrite of our software to not depend on ANY open source solutions at all! And I'm sure if I were to scan packages with another type of scanner, different sets of vulnerabilities would be exposed. And I haven't even gotten to step 3 yet.
So this got me wondering...how do other organizations selling white labelled solutions go about disclosing vulnerabilities to their end clients and how do they protect themselves?
I started thinking that maybe I don't have to deal with every single security vulnerability that exists. Instead, I should only address security issues that I am confident hackers will exploit or things that are easy to address. Then I hire a security party firm to find other vulnerabilities. Anything that's not caught by the security firm we deem as "not important". And we develop some contract and service agreement that protects our business from the legal actions if our clients experiences a security vulnerability not covered in our report?
But then, a customer will say, "But dockerhub.com clearly shows vulnerability X, and you as the seller were aware of vulnerability X, please justify to us why you did not address it." And how do we respond then?
That's what's in my head right now.
So back to my original question - what steps should a team take to address security concerns of a software that will be white labelled and sold to customers?
Hi there,

Best advice anyone will tell you, whether it's security or developer, is the following:
There is only so much you can do to properly secure things. You can have a hold of all potential vulnerabilities from identifiable attack vectors, but there will be someone with enough patience and tools at their disposal to find something no one thought about. With that said, I strongly suggest you patch up all found vulnerabilities and retest. Once you do that, include patch details in your report. Also, as a piece of wisdom: "Anything that's not caught by the security firm we deem as 'not important' "...That sentence right there made me cringe so bad it's not even funny. It should never be deemed "not important". I'll be more than happy to provide my services at no cost to retest 🙂
 
@Antero360 @simong1993 I love both your answers!

Antero360! You may not have found it funny, but I am very happy that you cringed!!!!! So happy that I'm laughing. I love things that are "not important". hahah! Thank you very much to both of you for your insights!
 
@Antero360 @simong1993 I love both your answers!

Antero360! You may not have found it funny, but I am very happy that you cringed!!!!! So happy that I'm laughing. I love things that are "not important". hahah! Thank you very much to both of you for your insights!
lol Yes, I am fully aware of the air quotes that was said in lol, but given my background, that is still cringy no matter who said it and at what level of their career it was said XD
 
Back
Top Bottom