Oftentimes such scans are just "security spam" and report all sorts of things. Many a time it's completely irrelevant to our use case because we don't run eCommerce portals but API services for admins and vCenter/K8s.
For example, let's take a look at the first two CVEs:
1) CVE-2019-11068 - libxslt - I don't see how any of that applies to NetApp HCI or SF environments. "xsltCheckRead can return -1 for a crafted URL that is not actually invalid and is subsequently loaded". Users are administrators. If someone could show me how one admin with limited permissions can become another admin, I'd be interested. Otherwise, I don't see how this matters.
2) CVE-2019-14287 - sudo vulnerability. First, there are no users on mNode (or SolidFire nodes) except admins, so there's no harm in a sudoer becoming root. Second, the vulnerability - as per example exploit in the CVE - doesn't do anything (see below). Third, you can become root by simply switching to root - the only user there is (admin) is supposed to be able to become root.
Yes, you can limit IP access and NetApp HCI at least recommends to put mNode on a Management VLAN when deploying, so that only admins can access mNode in the first place. If your Mgmt node was on own LAN, exposed only to selected admins and vCenter, for example, it wouldn't get scanned in the first place.
But many users don't do that because it's "inconvenient", so vCenter, SolidFire MIP(s) and mNode MIP are all made accessible to VM Network.
If you haven't done that, you can move mNode to another network, although that may not be possible without reinstalling it (or reconfiguring, but there are no KBs for that as far as I know), or use other approaches such as iptables on mNode.
Because of Docker, there's a lot of rules already configured, so you'd have to be careful to just add additional rules that drop access to HCC/mNode management IP/port to all, and allow it to IPs that need access (which could be a handful, depending who and what needs access to that IP). These rules may need to be redeployed after mNode VM is redeployed or upgraded.
Another way is to install a secure proxy and allow access to mNode only to that proxy IP, and deal with access control on the proxy.
mnode ~ # iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-INGRESS all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
[...]
