search

mojaloop / design-authority-project

This is the Issue and Decision Log for tracking mojaloop and related Designs
Other
1 stars 2 forks source link

Preventing/Mitigating Open Source Supply Chain Attacks #88

Open lewisdaly opened 2 years ago

lewisdaly commented 2 years ago

Request Summary:

Open Source Module Supply Chain attacks pose a real risk to the community:

For example: https://www.zdnet.com/article/corrupted-open-source-software-enters-the-russian-battlefield/

In this case, a malicious package was inserted as a dependency for a widely used package, which ended up attacking users who had ip addressed in Russia.

How can we as a community best prevent these sorts of attacks from affecting the Mojaloop Community?

Request Details:

**Artifacts**: - [ ] https://www.zdnet.com/article/corrupted-open-source-software-enters-the-russian-battlefield/ **Dependencies**: - [ ] If Applicable ### **Accountability**: - **Owner:** @lewisdaly - **Raised By:** @lewisdaly , @millerabel ## **Decision(s)**: - **Approved By:** ### Details - [ ] Actual decision made as a result of discussion ## **Follow-up**: - [ ] Actions to implement the decisions
godfreykutumela commented 2 years ago

Guideline from Snyk - https://snyk.io/blog/publishing-malicious-packages/ and from Jfrog - https://jfrog.com/blog/mind-your-dependencies-defending-against-malicious-npm-packages/

godfreykutumela commented 2 years ago

Top line is to:

https://blog.logrocket.com/how-to-protect-your-node-js-applications-from-malicious-dependencies-5f2e60ea08f9/

godfreykutumela commented 2 years ago

From @pedrosousabarreto To sum up my opinion on this:

As I said, the most important to me is that we don't use dynamic version numbers like "lts" or "latest", the rest is just a suggestion on the process.

lewisdaly commented 2 years ago

From @pedrosousabarreto To sum up my opinion on this:

* I'm against using any form of dynamic version numbers in dockerfile or .nvmrc like "lts" or "latest", we should always use fixed numbered versions like "16.14.2" (in fact for everything, not just dockerfile and .nvmrc)

* We should have a repo with a json file that has the official allowed node.js versions, and a git check script that compares dockerfile and .nvmrc against this on every PR). Every 3 months, we can manually review and if needed update that json file with the adequate releases (from node.js official schedule).

* We can also have a script periodically scanning our repos and warning to slack everytime it finds a js/ts repo without a .nvmrc file, or finds non approved node.js versions in dockerfile or .nvmrc.

* When we release, we execute the above script to make sure everything is using the adequate versions, if not, we manually fix them at release time.

As I said, the most important to me is that we don't use dynamic version numbers like "lts" or "latest", the rest is just a suggestion on the process.

@godfreykutumela I think this comment belongs on #78 - can you please move it over there?

lewisdaly commented 2 years ago

https://snyk.io/blog/publishing-malicious-packages/ This one has some good practices around preventing the installation of malicious packages, but it's fairly outdated. Node has a lot of this stuff built in now (such as the package-lock.json)

I think we could look at developing a whitelist or something of that nature, but I think in general we should focus on best practices around code reviews, and have a culture around being skeptical when a new package is being added.

https://jfrog.com/blog/mind-your-dependencies-defending-against-malicious-npm-packages/ This one is more up to date, the npm-secure-installer looks like an interesting approach since it can stop sub-dependencies from being installed if they don't follow best practices around using a package-lock.json

package_checker also looks like an interesting utility that can look out for red flags, although I don't know where this would fit into our toolchain (maybe in a docker build)?

godfreykutumela commented 2 years ago

Thanks @lewisdaly for this input and we will keep this open until we decide additional package check measures to compliment existing checks which may not sufficient to prevent this types of attacks.

godfreykutumela commented 2 years ago

Hi @MichaelJBRichards and @mdebarros Initially we thought we can prevent these types of attacks based on our current NPM package checking measures but upon reflecting on this again Lewis suggested to explore additional measures above which we can discuss in our DA meeting so lets keep this open for a while!

MichaelJBRichards commented 2 years ago

Geoffrey?? Godfrey!

M

On Wed, 27 Apr 2022 at 08:03, Michael Richards < @.***> wrote:

Thanks for that, Geoffrey. Should we expect an investigative action as a consequence of this? If so, whose responsibility would it be?

Yours, Michael

On Wed, 27 Apr 2022 at 07:56, Godfrey Kutumela @.***> wrote:

Hi @MichaelJBRichards https://github.com/MichaelJBRichards and @mdebarros https://github.com/mdebarros Initially we thought we can prevent these types of attacks based on our current NPM package checking measures but upon reflecting on this again Lewis suggested to explore additional measures above which we can discuss in our DA meeting so lets keep this open for a while!

— Reply to this email directly, view it on GitHub https://github.com/mojaloop/design-authority-project/issues/88#issuecomment-1110615312, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALMZW4UKCZXITMWYLKUZLADVHDQJXANCNFSM5SUYE5KA . You are receiving this because you were mentioned.Message ID: @.***>

--

[image: Modusbox_Logos_Modusbox_Vertical_2C.png] http://www.modusbox.com/

Michael Richards, Financial Services Principal

ModusBox,

7525 SE 24th St., Suite 510,

Mercer Island, WA 98040, USA

  • <+44%207785%20360009>44 7785 360009 @. @.>

--

[image: Modusbox_Logos_Modusbox_Vertical_2C.png] http://www.modusbox.com/

Michael Richards, Financial Services Principal

ModusBox,

7525 SE 24th St., Suite 510,

Mercer Island, WA 98040, USA

godfreykutumela commented 2 years ago

Ownership is me and Lewis and participation is everyone in the DA @MichaelJBRichards

lewisdaly commented 2 years ago

Decision today: @lewisdaly to investigate how we can better use our process around npm audit to make sure we can tighten the process around ignoring some vulnerabilities

lewisdaly commented 2 years ago

I've done some more digging around our existing integrated tools, and here's a summary on my latest thinking:

Goal: Determine how we can use our existing tools: npm audit, npm-audit-resolver and dependabot to prevent open source supply chain attacks

Questions I think we all want to answer:

Did we just get lucky on the last n npm hacks/flaws? Or is our processing working?

I need to come back to this - my plan is to look at the last Whitesource Audit and see if some of the more recent NPM flaws show up. It's hard to look back in time for security issues since we don't know if we (1) never depended on a given malicious module, (2) depended on a malicious module but our tooling works.

How can we make our process more robust to protect the codebase without adding too much governance (e.g. whitelisting npm packages) or work?

Case Study: EJS

da_central_ledger

da_central_ledger2

My lowest-hanging-fruit proposal here is:

e.g.:

npm audit fix
# after running 
# 15 vulnerabilities (3 moderate, 12 high)

# this command passes
npm audit --omit=dev --audit-level=critical 

# this command fails:
npm audit --omit=dev --audit-level=high
lewisdaly commented 2 years ago

Whitesource vs NPM Audit

repo # whitesource # npm audit
central-ledger 8 9
account-lookup-service 9 13
central-services-shared 6 7
sdk-scheme-adapter 7 7
ml-testing-toolkit 7 7
thirdparty-api-svc 7 8

White these numbers may not line up at a top level, the discrepencies can be explained by:

central-ledger

Whitesource found 11, 8 deduplicated:

npm audit found 10, 9 deduplicated:

account-lookup-service

Whitesource found 12, 9 deduplicated

npm audit found 17, 13 deduplicated:

It looks like some of these may not have been vulnerable ~2 weeks ago when I last ran the whitesource scan.

central-services-shared

Whitesource found 8, 6 deduplicated:

npm audit found 8, 7 deduplicated:

sdk-scheme-adapter

Whitesource found 10 total, 7 deduplicated:

npm audit found 7:

ml-testing-toolkit

Whitesource found 12 total, 7 deduplicated:

npm audit found 7

thirdparty-api-svc

Whitesource found 9 total, 7 deduplicated

npm audit found 9 total, 8 deduplicated:

bushjames commented 3 months ago

SBoM work helps mitigate...Moving to review, new ticket(s) to be opened to cover specifics if necessary.

godfreykutumela commented 3 months ago

Hi @bushjames, SBOM is just a listing of what is used to build the software, which is one of the many steps required in the open-source risk chain. Since this is pretty old, you can close it, and it could be re-opened in a new context.

bushjames commented 2 months ago

Update from @elnyry-sam-k: SBOM progressing well. To be presented at upcoming DA call. Work on provenance of all mojaloop dependencies and artifacts is in progress. Some recommendations have been made which are being assessed.