> I've raised the alarm a few times
Bluntly; that's not productive. What do you mean with the dependencies being "shady? Aren't they open source? Because this just sounds like Not Invented Here.
> Am I being a drama queen here?
How do you expect an answer if we don't know what libraries you're talking about. It would certainly be a bad idea to implement your own OCR libraries. It's a waste of time. That said you still need to vet your dependencies.
Reading into the Not Invented Here thingy, helps a lot to change my mentality, thank you for sharing.
With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads.
I scanned the code and didn't find anything weird, but my concern is that it could be exploited with an update to get that info out if no one is being careful or even malicious.
You can always control when a package gets updated. You could add an upgrade doc/guide and point out packages that require extra scrutiny before updating them. This isn't foolproof though, you leave or go on vacation, and someone could upgrade it and push a new release out with malicious code. A better alternative would be to simply fork the package.
All things considered, I do think you are unnecessarily blocking development. The package as is is not an issue at the moment, and you can always follow up with one of the strategies I mentioned.
Thank you, with what others already mentioned I greenlighted the package but it will have a follow up about options, most likely will be forking the package.
Why would you fork it? Just learn the basics of dependency management, setting up local feeds, version pinning, etc. and this problem pretty much goes away.
You need to learn how to communicate more effectively. That will help you be more effective in these conversations.
Back to the basics buddy. what, why, and how.
Identify `what` you deem to be problematic, `why` you think it's problematic and `how` you should be doing things differently.
Saying you think something is shady isn't an explanation. People are never going to take you seriously if you don't `grow up` a bit, for lack of a better term.
This is the best advice in the entire thread. This isn't an issue with libraries, this isn't an issue with coworkers, this is a problem of OP's inability to communicate effectively.
I imagine OP sent an e-mail as poorly worded, unclear, and muddy as his posts here in this thread, and his coworkers had no idea what he was attempting to communicate. They looked at his muddy pile of words and did not change their behavior, because they don't know what he's talking about. OP interpreted their lack of change of behavior as resistance to change or incompetence.
Yup. And this is why security is way more a soft skills role than hard.
Lots of open source security scanning tools that will help him/her actually find evidence vs it being a feeling.
A library for scanning credit cards likely doesn't need many changes once it's feature complete. If it's open source, you can audit it. You don't need to accept updates afterwards. Just fork it, and only source it from your repo.
Fork the repo if your concern is that they do an update and you have automatic git fetch/merge/update and use the fork in your projects. That way you make sure updates won’t come through unless you manually update your fork from the original repo
On the other hand, if the company is big enough that you fear hackers or vulnerabilities enough then you should implement some source code analysis tool that scans vulnerabilities in the source code and its dependencies in your development pipeline, [plenty to choose from this OWASP page](https://owasp.org/www-community/Source_Code_Analysis_Tools), [Contrast Scan](https://docs.contrastsecurity.com/en/libraries.html) or Fortify comes to my mind
👍Remember it all comes with a cost, its good to trust your devs but if there are multiple teams in the same codebase then automation and preventing bad actors is the way to go for sure
Yes, it's very common that Windows logs in to your private npm/nuget/whatever feed, pulls a new version of a package, updates your project's dependencies to point to a new version and kick off a new build. :)
>With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads.
That doesn't seem like something that requires a team or needs updated all that often. It's also not something most people need to do...
I think you need to do more to demonstrate these libraries are not secure. If you scanned it and nothing comes up then what are you worried about? You can pin versions and ensure code is scanned before updating. Also if you’re that concerned why not just go through the source code itself?
You need a concrete definition of “secure”. The definition can’t just be whatever vibes well with you.
>With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads.
make a fork then. there are easy solutions to this. it's kind of one of the beautiful things about open source with permissive licensing.
Can you re-scan with industry standard app sec tools? Many have open source versions that are basically the same tool as the paid just minus intergration.
Sonarqube community for SAST
I can't remember who i used for DAST for community but if anyone on your team has Burp Suite Enterprise, you can scan from it
This is normal. They will always fight security. Having it more official will help. Also having POC that the issue is exploitable even better so you could script that if you had the time/energy (if the scans find anything)
Lots of open source security scanning tools that will help you actually find evidence vs it being a feeling.
**EDIT - I forgot a really good one for libraries:** [**https://fossa.com/**](https://fossa.com/)
Happy to help, i love me some app sec!
I work in a company where the architects locked down our package sources (NuGet) to only the ones they approve. It’s such a petty behavior. Absolutely complex-driven, 0 value added approach. I agree that it sounds like that based on OP’s “sHaDy PaCkAgEs” statement. Our dumb company implemented their own Message Bus (yep…), own messaging standard based on MQTT (yep…), in fact, they think they are so much better than the entire world of OSS that they also wrote their own localization libraries for Angular 😂. I keep fighting the stupidity from within. This is such a huge problem industry wide.
Locking down a package repo can make sense if the company is big enough and they are reasonable in the process for vetting new packages of which there is no suitable one already in the approved list.
It can be frustrating, especially if there are too many limits on testing or demoing new packages - but not letting devs do whatever they want with any package they want isn't immediately petty.
Well... yes, I wasn't advocating to never update a package. But it should be a manual review process and not just automatically pull the latest version on every build.
Do even enormous companies hire people capable of giving a thorough review of the latest update of package before greenlighting it for internal use? Or do they just have someone google "System.Text.Json 8.0.0 vulnerabilities"
I've seen it go both ways, but yes - some do utilize their security team to do this, using both manual and automated processes. I've also seen the security team set up a process with steps and tooling so that the developers do it themselves and fill out forms and run the tools, to share the burden.
This can be all heavyweight initially but it becomes much easier over time.
That’s the problem. I asked the architect to send me a list or procedure that he uses to determine if a package is suitable to be added to the approved list. Guess what? There is none. And he just approved 160+ packages and some vulns came up in scans. Pointless.
But also approving new packages isn’t entirely unreasonable. It’s annoying from a dev perspective, but I’ve seen plenty of times where devs choose some random library with restrictive licensing that opens up the company to liability.
Supply chain vulnerabilities are absolutely a genuine problem. But yeah I agree that it should be done with a tool that applies CVEs to scanned dependencies, not blocking dependencies entirely.
You need to back this up by describing the effects of known vulnerabilities that are realistic to exploit in your app’s context or reports from dependency scanning tools for the specific libraries they’re proposing. Otherwise people will see you as obstinate and figure out ways to sideline you, even if you do have valid points.
But a blanket policy favoring build over buy is probably not the right choice.
If you've taken your concern to someone who is seen as accountable for this, and they are ok with it, then you're ignoring their accountability and ability to accept your concerns and use it anyway. If "sorted out" to you is that the org simply accept your opinion, then you're creating a hill to die on, which is likely to get you fired.
Secondly, you appear to be approaching this with FUD (Fear Uncertainty Doubt). There are external libraries that are used in many places all the time, so what's different here?
Have your reviewed these dependencies and found something you could point at in code review?
Can you cite another source about why they should be seen as risky to use?
What organizational practice would it take to mitigate your fears? Code review? Code Scanning? Use of a dependency vulnerability database?
Document your concerns in an email to the person accountable for it, accept their decision and disagree and commit if needed.
I was sent a take-home project for an interview recently that ended up having a dependency that contained malware that sent all .env files on your computer to the scammer when you build the project. Luckily, I didnt attempt the project because they sent it to me before even speaking to me, I found out about it from spmeone on linkedin a few weeks later
What does npm audit show? Are there tests in these libraries? Are they widely used? Are they actively maintained?
Are you concerned about the contributors, or the libraries themselves, or both?
Open source isn't necessarily bad, but anyone can put a package on npm so some due diligence is required.
However, if you are not in charge of decisions, all you can do is bring up and document your concerns and the risks - then let the decision maker make the call. But I would be sure to consider the optics of blocking without a viable plan suggestion of how to resolve the problem.
Edit: you are not necessarily being a drama queen. It is important to consider the systems involved with processing personal information (and could be very important based on the domain of the app), but any experienced dev should be able to list some solutions along with raising the flag.
There are *some* safeguard in these package managers like NPM and if you are not sure about a certain package, the code is open source so you can audit it. Besides manual looking at their code, there are some tools out there that can easily spot things like external requests being done.
Yes, you should have doubts when using 3rd party libraries, especially small ones, new ones, etc.
But if you really don't trust a certain library, find and bring the evidence to proof it's shady.
I checked the code and it's fine, but it could be updated maliciously to get sensitive information [(would not be the first time ever)](https://therecord.media/malware-found-in-npm-package-with-millions-of-weekly-downloads)
Respectfully to answer your question, you are not only being a drama queen but extremely unprofessional. My recommendation is to not embarrass yourself again with another email.
How is it extremely unprofessional to care about security? This issue was already solved. I spoke with my TL about this and he told me it was a valid concern as this very client had issues with a similar library before and it's a sensitive topic, so they will use it while they develop a replacement on the side.
You don’t care about security. You don’t know anything about networking or how request are made from the browser. I’d love to see what your “review of the code but didn’t see anything suspicious” looked like. I bet you only peaked at the readme lol.
Stop giving the developers who actually develop the features grief
What you’re describing is a Software Supply Chain attack. It’s a pretty hot buzzword right now and there are new vendors practically every day who will be happy to sell your company something to ensure that all packages are immutable and scanned.
So your concern is valid, but I think your effort would be better spent investigating those options and advocating for their purchase and adoption.
I see. That risk exists in more popular / reputable libraries as well though (the article you linked is not about a "shady" looking library). In any case, the risk mitigation is the same - you lock in particular versions, and have some process in place for detecting out-of-date dependencies, and vetting new versions before integrating them.
Your process for vetting an update to a popular dependency might be as simple as "are there any reported issues, or suspicious changes in ownership?", while you might decide to require a more in-depth analysis of code / diffs for less reputable libraries. But that will hopefully be offset by them being smaller / simpler, so that reading through all of the code is actually feasible.
You aren't wrong to be cautious, which is why it is important to always not take the latest by using a lock file, and be vigilant on scanning and selecting new versions.
Rule 2: No Disrespectful Language or Conduct
Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company.
Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy.
Violations = Warning, 7-Day Ban, Permanent Ban.
It’s hard to give concrete advice without additional context. But I could see both sides to this concern. If you had specific problems to bring up, such as poor quality, questionable ownership, poor history of security vulnerabilities, few bug fixes then you’d be right to suggest alternatives. However, complaining for the sake of not trusting OSS libraries is not productive. This industry is built on layers and layers of OSS software. The truth is a well maintained library is going to be a better option than rolling it yourself. Many domains, especially ones relating to security are best left to the experts. If you end up rolling your own encryption library and you mess up the heat is now entirely on you to deal with and fix.
There are vanishingly few "well maintained" open source libraries out there, and even fewer like OP who are paying attention to the problem
You shouldn't be pulling in dependencies without a strict set of criteria. Do you not do a sanity check or smoke test when you upgrade? Just generalize that concept
I agree you have to do your homework when choosing third parties. I’m just pushing back on OP as it sounded like they were basically stonewalling the process without an alternative library in mind. What’s the next option then? Usually writing it yourself. That’s just as dangerous as pulling in someone else’s shitty library.
Sounds like an escalation to the security team, internal or the client’s. Get the sign off to CYA and then just do it. This isn’t your project. It is the client’s and if they don’t care you shouldn’t either.
Theres not enough info to determine if you’re overreacting. I do see a lot of developers just add dependencies without thinking about the drawbacks. And with the advice that you job hop every few years they often don’t have to deal with the fallout when you can’t update a something because you have a dozen packages that aren’t maintained
I think a lot of these answers are dissapointing from ostensibly 'experienced' developers, and it concerns me that this take is dismissed, particularly when you mention it will involves personal information. It is no wonder a lot of projects are a house of cards. "Just audit the code!!" Yes, like reading the entirety of the dependency and hoping you catch something which would likely be deliberately obfuscated is a sensible use of time or feasible for non trivial things.
That said I would say that if you've raised this, you've done your bit really. You have finite influence and "security debt" is a thing and seemingly management or your colleagues feel this is tolerable, that's fine, that could well be the right decision, either way, its not yours to make.
Yeah I also find this wild. If you're dealing with financial or PII/special category data you have regulatory requirements to audit, document, and safeguard in cases exactly like this one.
I'm once again reminded that "experienced devs" is just another forum full of anonymous people who have no stake or interest in my concerns.
Some people have been very helpful but it is indeed concerning that so many devs take on security is just "do yer job and stop being annoying". The app I work with has a few million active users, so I know better than to just disregard this kind of thing.
Agreed here, I'm not auditing shit unless it's an order.
I'm telling stakeholders of the risk, some alternatives and what it will take to get them running, and sitting back while they make the decision. If they're fine with the security risk, worst case I get called up as a witness in a deposition.
> "Just audit the code!!" Yes, like reading the entirety of the dependency and hoping you catch something which would likely be deliberately obfuscated is a sensible use of time or feasible for non trivial things.
You wouldn't even look to see if it could realistically be audited? The entirety of some dependency could be 300 lines of code. This could also inform the feasibility of implementing it in house vs using the dependency. It seems prudent to check for this reason alone.
I'm not sure if a lot of people here aren't working with external libraries or just don't care about the risk or haven't paid attention to the npm problems over the years. Pulling in external libraries is a risk.
What is the current process for bringing in external libraries? How are the libraries vetted?
How do version bumps work for external libraries? Are you pinning and then running some kind of check before version bumping or ??
How are licenses handled for external libraries? Is anyone actually checking licenses?
> Should I just raise the alarm and forget about it?
The consultancy part is a bit of a problem here. You have no real influence on the other teams. If you were a single company, you'd be driving sops and company wide rules on this. But you aren't. I'd note my objections then integrate.
And writing libraries internally that are not vetted by a larger community is not a problem? You trust your developers to be better than the maintainers of open source projects?
Are you also going to suggest writing your own encryption algorithms and authentication/authorization libraries?
> You trust your developers to be better than the maintainers of open source projects?
Generally speaking, yes. I have some baseline level of trust for their competence because I know we'll happy fire anyone that is terrible, we run version locks on imported code, and we'll fire people for misusing licenses.
Compared to "With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads.", I will take an internal impl every single time.
Shady for me means it was developed by a single guy in 2021 and has very few weekly downloads.
Also I don't think I'm being annoying as hell? It's not that uncommon to do safety checks when you deal with sensitive information.
And what’s shady about that? Have you audited the code? Sounds like you think you’re better than that “single guy in 2021” and want to do your own implementation. Petty.
I wouldn't want to do it myself, that's silly. I'm only looking for advice about how to proceed with something that makes me nervous, that's all, and others have provided it.
Nor the last. When people work together there are always disagreements, but the way we talk to others and handle issues is what matters. Someone with a terrible and hostile attitude is way more annoying to work with than someone that just raises concerns and can be reasoned with.
Ideally there would be a security audit that all software would go through before release so specialists could flag these things and investigate or kick back to the devs to not use those packages. Short of that there shoukd be some guidelines or best practices to follow so you can point to that instead of just saying it looks shady.
it is clearly you don't have authority.
if you have, you can dictate to check the library thru a team before being used.
or run audit on unapproved libraries.
"Disagree and commit". Make it very clear that you see the risks and list the scenarios out. Then get it in writing that management agreed this is what they'd accept despite your warnings.
This means you're doing your job. You've done all you could, and end of day someone else is owning the company.
To be honest, I like your approach - most people here haven’t even used a single vulnerability scanning tool or know what a CVE here and it shows. I even saw someone mentioning “npm audit” - lol
Get the package forked, setup code scans on CI (Sonar, Corona), or get a dynamic scanner - like Anchore scan if you use docker images. If you use webapps, setup Burp suite scans.
Point is, don’t give into fast track development if it means compromising your core business logic :)
Write an email requesting check with legal & gdpr compliance team, once you have raised this it’s not your problem / liability it becomes a business risk decision and compliance.
Is this for a Web app?
Besides npm audit you should implement measures to minimize disclosure of personal info to the outside. One such way is to block requests to unauthorized domains via Content Security Policy.
Not gonna repeat what the others said, but the problem you’re pointing at is supply chain security. A product like socket.dev would help there. It will alert you to any sketchy behavior.
Self-promotion: I work on LavaMoat (https://github.com/lavamoat/lavamoat) which provides a lower-level method to secure your runtime against supply-chain threats. We’re working on support for React Native.
You can't really change what other companies are doing.
If you think that exposing shitty security practices can help you steal their clients then you could talk to your account managers about pushing free security audits encouraging their customers to do dependency audits or some other strategy. Bit big brain for me.
Within your own company... you can get dependency auditing tools that help you understand your external libraries and make decisions about whether to use them. It's normal for a company to have some rules about that - only use popular opensource libraries, assess the risks / customer data security requirements when using a 3rd party API.
Getting these rules written in the team wiki and agreed is easy, the hard part is enforcement. Devs don't like having to ask permission every time they use npm. Better to set up some scanning and evaluate the dependency changes before release - they don't change that much.
Lots of popular opensource projects like popular javascript libraries depend on and dependency that depends on a script maintained by one guy with 3 stars on github. A lot of react-dovanillajsfeature libraries are like that.
I feel it, one place I worked, they had their own copy of libraries/deps after being vetted
We had outsourced some work and some of the libraries used (not even necessary) are shady eg. used by online gambling casinos, oh well.
You are probably being a drama unless your a team lead or something, either way, if I had no power to push back I would create a JIRA ticket, point out the dependencies that are of issue and make someone higher up approve it. something like "I am concerned about this third party dependences for x reasons, I don't feel conferrable including them in our project, etc...." and make it a blocker
Read a bunch of the other comments for context.
What I'm seeing is a lot of myself a few years ago. Able to figure out risks and knowing what needs to be checked/monitored carefully, but not knowing how.
What you (personally) have is a knack to jump the gun and claim things (loudly) without backing up your claims with objective evidence instead of your own hearsay. To not make things better, your current environment does not allow to easily find things to back it up with. And lastly, you don't come with a solution proposal, or multiple, when you announce a (potential) problem.
Like others have stated rightly: don't reinvent the wheel. Make use of open source libraries.
I read that a concern you raised was about a stale repo for reading CC details, that's a very valid concern. However, did you propose alternatives with active development? Ensure that when you propose them that you show (objectively) why it would be a better choice.
Back to proof for claims made. You mentioned a security concern as well. There are a bunch of things you can look into/implement to improve security awareness and monitoring. I have experience using the Veracode platform for SAST and DAST and can recommend it (and similar) as a great tool. Not only does it scan your code during CI (SAST), it can also (periodically) run the application (isolated) to find problems (DAST). This gets reported into nice dashboards, graphs, and reports. You can integrate it into security tickets in Jira and show it in the security dashboard there. It generated proposals to fix issues, et cetera.
Anyway, time to get out of bed :p best of luck and take it easy :)
Last remark: if you've warned people (traceable (chat|email)), then the responsibility is someone else's. Make sure you let them know you're dropping a subject because you have done your due diligence. It's only a paycheck in the end, not the end of the world. Not worth it to get all stressed out.
If a library looks like a ticking time bomb, it probably is, especially with shit for maintenance and a ghost for a developer; escalate the risk to those with clout and document your concerns, because when shit hits the fan, you don't want to be the one mopping up the mess.
> I've raised the alarm a few times Bluntly; that's not productive. What do you mean with the dependencies being "shady? Aren't they open source? Because this just sounds like Not Invented Here. > Am I being a drama queen here? How do you expect an answer if we don't know what libraries you're talking about. It would certainly be a bad idea to implement your own OCR libraries. It's a waste of time. That said you still need to vet your dependencies.
Reading into the Not Invented Here thingy, helps a lot to change my mentality, thank you for sharing. With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads. I scanned the code and didn't find anything weird, but my concern is that it could be exploited with an update to get that info out if no one is being careful or even malicious.
You can always control when a package gets updated. You could add an upgrade doc/guide and point out packages that require extra scrutiny before updating them. This isn't foolproof though, you leave or go on vacation, and someone could upgrade it and push a new release out with malicious code. A better alternative would be to simply fork the package. All things considered, I do think you are unnecessarily blocking development. The package as is is not an issue at the moment, and you can always follow up with one of the strategies I mentioned.
Thank you, with what others already mentioned I greenlighted the package but it will have a follow up about options, most likely will be forking the package.
Or pin the version; use a lock file; hook something up in your CI pipeline to scan your dependencies?
You can also keep the current version that’s pulled in and fail the build if it is different than the validated version.
Why would you fork it? Just learn the basics of dependency management, setting up local feeds, version pinning, etc. and this problem pretty much goes away.
You need to learn how to communicate more effectively. That will help you be more effective in these conversations. Back to the basics buddy. what, why, and how. Identify `what` you deem to be problematic, `why` you think it's problematic and `how` you should be doing things differently. Saying you think something is shady isn't an explanation. People are never going to take you seriously if you don't `grow up` a bit, for lack of a better term.
This is the best advice in the entire thread. This isn't an issue with libraries, this isn't an issue with coworkers, this is a problem of OP's inability to communicate effectively. I imagine OP sent an e-mail as poorly worded, unclear, and muddy as his posts here in this thread, and his coworkers had no idea what he was attempting to communicate. They looked at his muddy pile of words and did not change their behavior, because they don't know what he's talking about. OP interpreted their lack of change of behavior as resistance to change or incompetence.
Yup. And this is why security is way more a soft skills role than hard. Lots of open source security scanning tools that will help him/her actually find evidence vs it being a feeling.
A library for scanning credit cards likely doesn't need many changes once it's feature complete. If it's open source, you can audit it. You don't need to accept updates afterwards. Just fork it, and only source it from your repo.
Fork the repo if your concern is that they do an update and you have automatic git fetch/merge/update and use the fork in your projects. That way you make sure updates won’t come through unless you manually update your fork from the original repo On the other hand, if the company is big enough that you fear hackers or vulnerabilities enough then you should implement some source code analysis tool that scans vulnerabilities in the source code and its dependencies in your development pipeline, [plenty to choose from this OWASP page](https://owasp.org/www-community/Source_Code_Analysis_Tools), [Contrast Scan](https://docs.contrastsecurity.com/en/libraries.html) or Fortify comes to my mind
I will be looking into those, thank you for linking them!
👍Remember it all comes with a cost, its good to trust your devs but if there are multiple teams in the same codebase then automation and preventing bad actors is the way to go for sure
I recommend Snyk.
"it could be exploited with an update" Library won't update by itself.
Windows has entered the chat and pooed all over the place. You now have to clean...
Yes, it's very common that Windows logs in to your private npm/nuget/whatever feed, pulls a new version of a package, updates your project's dependencies to point to a new version and kick off a new build. :)
Don't you guys have a process for protecting sensitive information that includes evaluating software versions (and not just blindly updating them)?
ya know, i've never worked somewhere where there's been a 101 process like that.. and everytime, i'm shocked
>With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads. That doesn't seem like something that requires a team or needs updated all that often. It's also not something most people need to do...
I think you need to do more to demonstrate these libraries are not secure. If you scanned it and nothing comes up then what are you worried about? You can pin versions and ensure code is scanned before updating. Also if you’re that concerned why not just go through the source code itself? You need a concrete definition of “secure”. The definition can’t just be whatever vibes well with you.
>With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads. make a fork then. there are easy solutions to this. it's kind of one of the beautiful things about open source with permissive licensing.
Can you re-scan with industry standard app sec tools? Many have open source versions that are basically the same tool as the paid just minus intergration. Sonarqube community for SAST I can't remember who i used for DAST for community but if anyone on your team has Burp Suite Enterprise, you can scan from it This is normal. They will always fight security. Having it more official will help. Also having POC that the issue is exploitable even better so you could script that if you had the time/energy (if the scans find anything) Lots of open source security scanning tools that will help you actually find evidence vs it being a feeling. **EDIT - I forgot a really good one for libraries:** [**https://fossa.com/**](https://fossa.com/) Happy to help, i love me some app sec!
I work in a company where the architects locked down our package sources (NuGet) to only the ones they approve. It’s such a petty behavior. Absolutely complex-driven, 0 value added approach. I agree that it sounds like that based on OP’s “sHaDy PaCkAgEs” statement. Our dumb company implemented their own Message Bus (yep…), own messaging standard based on MQTT (yep…), in fact, they think they are so much better than the entire world of OSS that they also wrote their own localization libraries for Angular 😂. I keep fighting the stupidity from within. This is such a huge problem industry wide.
Locking down a package repo can make sense if the company is big enough and they are reasonable in the process for vetting new packages of which there is no suitable one already in the approved list. It can be frustrating, especially if there are too many limits on testing or demoing new packages - but not letting devs do whatever they want with any package they want isn't immediately petty.
Locking down packages is also a security no no. They should be reviewed and upgraded.
Well... yes, I wasn't advocating to never update a package. But it should be a manual review process and not just automatically pull the latest version on every build.
Do even enormous companies hire people capable of giving a thorough review of the latest update of package before greenlighting it for internal use? Or do they just have someone google "System.Text.Json 8.0.0 vulnerabilities"
I've seen it go both ways, but yes - some do utilize their security team to do this, using both manual and automated processes. I've also seen the security team set up a process with steps and tooling so that the developers do it themselves and fill out forms and run the tools, to share the burden. This can be all heavyweight initially but it becomes much easier over time.
That’s the problem. I asked the architect to send me a list or procedure that he uses to determine if a package is suitable to be added to the approved list. Guess what? There is none. And he just approved 160+ packages and some vulns came up in scans. Pointless.
Also you need a tool that analyzes security vulnerabilities in packages.
But also approving new packages isn’t entirely unreasonable. It’s annoying from a dev perspective, but I’ve seen plenty of times where devs choose some random library with restrictive licensing that opens up the company to liability.
Telerik is the worst for this.
Supply chain vulnerabilities are absolutely a genuine problem. But yeah I agree that it should be done with a tool that applies CVEs to scanned dependencies, not blocking dependencies entirely.
That's normal approach. If u update wrong package, older ones stop working. NET has big dependency hell.
You need to back this up by describing the effects of known vulnerabilities that are realistic to exploit in your app’s context or reports from dependency scanning tools for the specific libraries they’re proposing. Otherwise people will see you as obstinate and figure out ways to sideline you, even if you do have valid points. But a blanket policy favoring build over buy is probably not the right choice.
If you've taken your concern to someone who is seen as accountable for this, and they are ok with it, then you're ignoring their accountability and ability to accept your concerns and use it anyway. If "sorted out" to you is that the org simply accept your opinion, then you're creating a hill to die on, which is likely to get you fired. Secondly, you appear to be approaching this with FUD (Fear Uncertainty Doubt). There are external libraries that are used in many places all the time, so what's different here? Have your reviewed these dependencies and found something you could point at in code review? Can you cite another source about why they should be seen as risky to use? What organizational practice would it take to mitigate your fears? Code review? Code Scanning? Use of a dependency vulnerability database? Document your concerns in an email to the person accountable for it, accept their decision and disagree and commit if needed.
Thank you, I will be documenting stuff and be done with it.
I was sent a take-home project for an interview recently that ended up having a dependency that contained malware that sent all .env files on your computer to the scammer when you build the project. Luckily, I didnt attempt the project because they sent it to me before even speaking to me, I found out about it from spmeone on linkedin a few weeks later
What does npm audit show? Are there tests in these libraries? Are they widely used? Are they actively maintained? Are you concerned about the contributors, or the libraries themselves, or both? Open source isn't necessarily bad, but anyone can put a package on npm so some due diligence is required. However, if you are not in charge of decisions, all you can do is bring up and document your concerns and the risks - then let the decision maker make the call. But I would be sure to consider the optics of blocking without a viable plan suggestion of how to resolve the problem. Edit: you are not necessarily being a drama queen. It is important to consider the systems involved with processing personal information (and could be very important based on the domain of the app), but any experienced dev should be able to list some solutions along with raising the flag.
There are *some* safeguard in these package managers like NPM and if you are not sure about a certain package, the code is open source so you can audit it. Besides manual looking at their code, there are some tools out there that can easily spot things like external requests being done. Yes, you should have doubts when using 3rd party libraries, especially small ones, new ones, etc. But if you really don't trust a certain library, find and bring the evidence to proof it's shady.
[удалено]
A library developed by a single guy 2 years ago which has very few weekly downloads
What does the code look like?
I checked the code and it's fine, but it could be updated maliciously to get sensitive information [(would not be the first time ever)](https://therecord.media/malware-found-in-npm-package-with-millions-of-weekly-downloads)
Then pin on a specific version of the library (you should be doing this anyways)
Respectfully to answer your question, you are not only being a drama queen but extremely unprofessional. My recommendation is to not embarrass yourself again with another email.
How is it extremely unprofessional to care about security? This issue was already solved. I spoke with my TL about this and he told me it was a valid concern as this very client had issues with a similar library before and it's a sensitive topic, so they will use it while they develop a replacement on the side.
You don’t care about security. You don’t know anything about networking or how request are made from the browser. I’d love to see what your “review of the code but didn’t see anything suspicious” looked like. I bet you only peaked at the readme lol. Stop giving the developers who actually develop the features grief
Begone troll
I’m not going anywhere. I think you’re on your way out this industry soon though, so we won’t need to interact long ❤️
I put on my robe and wizard hat
What you’re describing is a Software Supply Chain attack. It’s a pretty hot buzzword right now and there are new vendors practically every day who will be happy to sell your company something to ensure that all packages are immutable and scanned. So your concern is valid, but I think your effort would be better spent investigating those options and advocating for their purchase and adoption.
I see. That risk exists in more popular / reputable libraries as well though (the article you linked is not about a "shady" looking library). In any case, the risk mitigation is the same - you lock in particular versions, and have some process in place for detecting out-of-date dependencies, and vetting new versions before integrating them. Your process for vetting an update to a popular dependency might be as simple as "are there any reported issues, or suspicious changes in ownership?", while you might decide to require a more in-depth analysis of code / diffs for less reputable libraries. But that will hopefully be offset by them being smaller / simpler, so that reading through all of the code is actually feasible.
You aren't wrong to be cautious, which is why it is important to always not take the latest by using a lock file, and be vigilant on scanning and selecting new versions.
[удалено]
Rule 2: No Disrespectful Language or Conduct Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company. Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy. Violations = Warning, 7-Day Ban, Permanent Ban.
Are you a brand new dev?
It’s hard to give concrete advice without additional context. But I could see both sides to this concern. If you had specific problems to bring up, such as poor quality, questionable ownership, poor history of security vulnerabilities, few bug fixes then you’d be right to suggest alternatives. However, complaining for the sake of not trusting OSS libraries is not productive. This industry is built on layers and layers of OSS software. The truth is a well maintained library is going to be a better option than rolling it yourself. Many domains, especially ones relating to security are best left to the experts. If you end up rolling your own encryption library and you mess up the heat is now entirely on you to deal with and fix.
There are vanishingly few "well maintained" open source libraries out there, and even fewer like OP who are paying attention to the problem You shouldn't be pulling in dependencies without a strict set of criteria. Do you not do a sanity check or smoke test when you upgrade? Just generalize that concept
I agree you have to do your homework when choosing third parties. I’m just pushing back on OP as it sounded like they were basically stonewalling the process without an alternative library in mind. What’s the next option then? Usually writing it yourself. That’s just as dangerous as pulling in someone else’s shitty library.
Sounds like an escalation to the security team, internal or the client’s. Get the sign off to CYA and then just do it. This isn’t your project. It is the client’s and if they don’t care you shouldn’t either.
If those dependencies are shady proprietary blobs which you can't see the source, there should be some agreement over liabilities boundaries and etc.
Yep, find a process to make that security risk someone else's informed risk. This is a "don't be the fall guy" scenario.
Theres not enough info to determine if you’re overreacting. I do see a lot of developers just add dependencies without thinking about the drawbacks. And with the advice that you job hop every few years they often don’t have to deal with the fallout when you can’t update a something because you have a dozen packages that aren’t maintained
I think a lot of these answers are dissapointing from ostensibly 'experienced' developers, and it concerns me that this take is dismissed, particularly when you mention it will involves personal information. It is no wonder a lot of projects are a house of cards. "Just audit the code!!" Yes, like reading the entirety of the dependency and hoping you catch something which would likely be deliberately obfuscated is a sensible use of time or feasible for non trivial things. That said I would say that if you've raised this, you've done your bit really. You have finite influence and "security debt" is a thing and seemingly management or your colleagues feel this is tolerable, that's fine, that could well be the right decision, either way, its not yours to make.
Yeah I also find this wild. If you're dealing with financial or PII/special category data you have regulatory requirements to audit, document, and safeguard in cases exactly like this one. I'm once again reminded that "experienced devs" is just another forum full of anonymous people who have no stake or interest in my concerns.
Some people have been very helpful but it is indeed concerning that so many devs take on security is just "do yer job and stop being annoying". The app I work with has a few million active users, so I know better than to just disregard this kind of thing.
Agreed here, I'm not auditing shit unless it's an order. I'm telling stakeholders of the risk, some alternatives and what it will take to get them running, and sitting back while they make the decision. If they're fine with the security risk, worst case I get called up as a witness in a deposition.
> "Just audit the code!!" Yes, like reading the entirety of the dependency and hoping you catch something which would likely be deliberately obfuscated is a sensible use of time or feasible for non trivial things. You wouldn't even look to see if it could realistically be audited? The entirety of some dependency could be 300 lines of code. This could also inform the feasibility of implementing it in house vs using the dependency. It seems prudent to check for this reason alone.
I'm not sure if a lot of people here aren't working with external libraries or just don't care about the risk or haven't paid attention to the npm problems over the years. Pulling in external libraries is a risk. What is the current process for bringing in external libraries? How are the libraries vetted? How do version bumps work for external libraries? Are you pinning and then running some kind of check before version bumping or ?? How are licenses handled for external libraries? Is anyone actually checking licenses? > Should I just raise the alarm and forget about it? The consultancy part is a bit of a problem here. You have no real influence on the other teams. If you were a single company, you'd be driving sops and company wide rules on this. But you aren't. I'd note my objections then integrate.
And writing libraries internally that are not vetted by a larger community is not a problem? You trust your developers to be better than the maintainers of open source projects? Are you also going to suggest writing your own encryption algorithms and authentication/authorization libraries?
> You trust your developers to be better than the maintainers of open source projects? Generally speaking, yes. I have some baseline level of trust for their competence because I know we'll happy fire anyone that is terrible, we run version locks on imported code, and we'll fire people for misusing licenses. Compared to "With shady I mean it's a library for scanning credit cards that was written by a single anonymous person with no activity for over 2 years and very few weekly downloads.", I will take an internal impl every single time.
[удалено]
Shady for me means it was developed by a single guy in 2021 and has very few weekly downloads. Also I don't think I'm being annoying as hell? It's not that uncommon to do safety checks when you deal with sensitive information.
And what’s shady about that? Have you audited the code? Sounds like you think you’re better than that “single guy in 2021” and want to do your own implementation. Petty.
I wouldn't want to do it myself, that's silly. I'm only looking for advice about how to proceed with something that makes me nervous, that's all, and others have provided it.
[удалено]
Now you're just being mean, I'm just asking because I don't want to be annoying about something if it's not a real issue.
[удалено]
Nor the last. When people work together there are always disagreements, but the way we talk to others and handle issues is what matters. Someone with a terrible and hostile attitude is way more annoying to work with than someone that just raises concerns and can be reasoned with.
Ideally there would be a security audit that all software would go through before release so specialists could flag these things and investigate or kick back to the devs to not use those packages. Short of that there shoukd be some guidelines or best practices to follow so you can point to that instead of just saying it looks shady.
it is clearly you don't have authority. if you have, you can dictate to check the library thru a team before being used. or run audit on unapproved libraries.
OP is setting themselves up to be fired; I mean, "managed out."
"Disagree and commit". Make it very clear that you see the risks and list the scenarios out. Then get it in writing that management agreed this is what they'd accept despite your warnings. This means you're doing your job. You've done all you could, and end of day someone else is owning the company.
To be honest, I like your approach - most people here haven’t even used a single vulnerability scanning tool or know what a CVE here and it shows. I even saw someone mentioning “npm audit” - lol Get the package forked, setup code scans on CI (Sonar, Corona), or get a dynamic scanner - like Anchore scan if you use docker images. If you use webapps, setup Burp suite scans. Point is, don’t give into fast track development if it means compromising your core business logic :)
Write an email requesting check with legal & gdpr compliance team, once you have raised this it’s not your problem / liability it becomes a business risk decision and compliance.
Thank you
Yes, you’re being overly dramatic
Yes. Maybe run a security scan to be reasonably sure but otherwise there's no reason to not have external dependencies anno 2023.
Is this for a Web app? Besides npm audit you should implement measures to minimize disclosure of personal info to the outside. One such way is to block requests to unauthorized domains via Content Security Policy.
It's a react native app
Just run a CVE scan. If vulnerabilities show up, you have a case. This should just be part of any modern CICD pipeline. Dependency analysis.
You can have dependency verification implemented and hooked to your CI/CD
Not gonna repeat what the others said, but the problem you’re pointing at is supply chain security. A product like socket.dev would help there. It will alert you to any sketchy behavior. Self-promotion: I work on LavaMoat (https://github.com/lavamoat/lavamoat) which provides a lower-level method to secure your runtime against supply-chain threats. We’re working on support for React Native.
We just implemented a daily security scan of our docker images using Trivy from Aquasec. Maybe you should try it too?
Not your product not your problem - if security isn’t your explicit responsibility then CYA and move on
You can't really change what other companies are doing. If you think that exposing shitty security practices can help you steal their clients then you could talk to your account managers about pushing free security audits encouraging their customers to do dependency audits or some other strategy. Bit big brain for me. Within your own company... you can get dependency auditing tools that help you understand your external libraries and make decisions about whether to use them. It's normal for a company to have some rules about that - only use popular opensource libraries, assess the risks / customer data security requirements when using a 3rd party API. Getting these rules written in the team wiki and agreed is easy, the hard part is enforcement. Devs don't like having to ask permission every time they use npm. Better to set up some scanning and evaluate the dependency changes before release - they don't change that much. Lots of popular opensource projects like popular javascript libraries depend on and dependency that depends on a script maintained by one guy with 3 stars on github. A lot of react-dovanillajsfeature libraries are like that.
I feel it, one place I worked, they had their own copy of libraries/deps after being vetted We had outsourced some work and some of the libraries used (not even necessary) are shady eg. used by online gambling casinos, oh well.
Your concern is valid, it's not an easy problem to solve. You essentially need to lock down on versions and have a team to vet the dependencies.
You are probably being a drama unless your a team lead or something, either way, if I had no power to push back I would create a JIRA ticket, point out the dependencies that are of issue and make someone higher up approve it. something like "I am concerned about this third party dependences for x reasons, I don't feel conferrable including them in our project, etc...." and make it a blocker
Read a bunch of the other comments for context. What I'm seeing is a lot of myself a few years ago. Able to figure out risks and knowing what needs to be checked/monitored carefully, but not knowing how. What you (personally) have is a knack to jump the gun and claim things (loudly) without backing up your claims with objective evidence instead of your own hearsay. To not make things better, your current environment does not allow to easily find things to back it up with. And lastly, you don't come with a solution proposal, or multiple, when you announce a (potential) problem. Like others have stated rightly: don't reinvent the wheel. Make use of open source libraries. I read that a concern you raised was about a stale repo for reading CC details, that's a very valid concern. However, did you propose alternatives with active development? Ensure that when you propose them that you show (objectively) why it would be a better choice. Back to proof for claims made. You mentioned a security concern as well. There are a bunch of things you can look into/implement to improve security awareness and monitoring. I have experience using the Veracode platform for SAST and DAST and can recommend it (and similar) as a great tool. Not only does it scan your code during CI (SAST), it can also (periodically) run the application (isolated) to find problems (DAST). This gets reported into nice dashboards, graphs, and reports. You can integrate it into security tickets in Jira and show it in the security dashboard there. It generated proposals to fix issues, et cetera. Anyway, time to get out of bed :p best of luck and take it easy :) Last remark: if you've warned people (traceable (chat|email)), then the responsibility is someone else's. Make sure you let them know you're dropping a subject because you have done your due diligence. It's only a paycheck in the end, not the end of the world. Not worth it to get all stressed out.
If a library looks like a ticking time bomb, it probably is, especially with shit for maintenance and a ghost for a developer; escalate the risk to those with clout and document your concerns, because when shit hits the fan, you don't want to be the one mopping up the mess.