• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Subscribers 97 subscribers
  • Views 3526 views
  • Users 0 members are here
Options
Related

Security issues with npm dependencies in Operations Support Portal?

sebastian.eberhard
over 2 years ago

Hi,

the Operations Support Portal and also API Server UI have dependencies to NPM packages. (KB 266000)

Recently, popular npm libraries, such as ua-parser, rc and coa were hijacked and infected with malware. 

See Embedded Malware in NPM: Coa, Rc, Ua-parser - FOSSA, Unbekannte infiltrieren Paketmanager npm und verseuchen Tools mit Schadcode | heise online

If packages used by One Identity HTML5 applications were compromised, our fear is that we might be using those packages when compiling One Identity Manager HTML 5 applications. This would compromise the security and integrity of our OIM customer installation, as well as potentially our systems and data. 

We are not experts in npm security. Therefore, as One Identity seems to shift more and more to HTML 5, we have the following questions:

- Is that a risk for OIM customers at all?

- If so, how do you mitigate security and integrity risks for npm packages compiled into OIM?

- How is One Identity protecting customers?

Thanks,

Sebastian

Parents
  • 0 over 2 years ago

    First of all there is to mention that we have a secure build process to ensure as much integrity as possible. More details can be obtained via our Security Director at One Identity.

    Part of this is a software compoistion scanning process, that is run with every bulld and keeps us notified constantly. There are goals defined for delivering fixes to such findings in a certain amount of days.

    Regarding the latest issue: In fact coa is part of the npm package dependcy list of our new web ui. In the specific coa case that just happened recently we were pinning the npm package to the latest not infected version (2.0.2). So nothing to do for us.

  • 0 over 2 years ago in reply to Matthias.Bauer

    That your build process is secure does not really help in your customers build processes. In addition, I doubt that since you're talking about pinning - and unless you are pinning every single dependency (the whole tree) that's possible only after somebody has marked the vulnerable versions for you (npm audit, snyk or something like that). However - more information about your build process might be really useful.

    In order to get the build process more secure, I want to limit the permissions of that process. Builds starts while developing (designer, web designer, api designer) and on deployment. At least whenever npm is involved, we have to be extremely cautious, since you load and execute all the dependencies from untrustworthy sources (and as I can see, you load them from scratch every time).

    So I wonder if there's a (supported) way to

    • compile in a containerized environment (docker)?
    • use a more restriced compile chain (e.g. start the build process/build tool with a restriced user - directly from the tools)
    • restrict users from compiling from the tools (so we can provide command line versions where we can use impersonation)
Reply
  • 0 over 2 years ago in reply to Matthias.Bauer

    That your build process is secure does not really help in your customers build processes. In addition, I doubt that since you're talking about pinning - and unless you are pinning every single dependency (the whole tree) that's possible only after somebody has marked the vulnerable versions for you (npm audit, snyk or something like that). However - more information about your build process might be really useful.

    In order to get the build process more secure, I want to limit the permissions of that process. Builds starts while developing (designer, web designer, api designer) and on deployment. At least whenever npm is involved, we have to be extremely cautious, since you load and execute all the dependencies from untrustworthy sources (and as I can see, you load them from scratch every time).

    So I wonder if there's a (supported) way to

    • compile in a containerized environment (docker)?
    • use a more restriced compile chain (e.g. start the build process/build tool with a restriced user - directly from the tools)
    • restrict users from compiling from the tools (so we can provide command line versions where we can use impersonation)
Children
No Data