From owner-freebsd-ports@freebsd.org Fri Feb 2 21:17:28 2018 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E1FDECAC0F for ; Fri, 2 Feb 2018 21:17:28 +0000 (UTC) (envelope-from andreas.sommer87@googlemail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A58C80ADA for ; Fri, 2 Feb 2018 21:17:28 +0000 (UTC) (envelope-from andreas.sommer87@googlemail.com) Received: by mail-wm0-x231.google.com with SMTP id f71so15274803wmf.0 for ; Fri, 02 Feb 2018 13:17:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Sz+mrBK89xjkL+4KPGqUUtot3v7TLC1YIgHop8RGoPg=; b=NNDLf+u8bMIwvY7d2lRYjkw4lDzHdz2O0c2aBiU6BXbXw1j2YymIwC8Ja4e04+GNec +pGetiwmQb0rI3P19mko5xuvfjYAH17vRX5IvCFxovZ2Rf7yKqfDJ0t1iVN6J2g2Jfyd IAzpHTLWucmbrQuVWBtW1L7hIk+YlgHJmmUySuCigl8lUkwG+u06hSShZUkXaiWtIfQ4 KOLeBRosjMwD7dztCcqgcc2pIVMGxi6Ld42r5z+5AGgd8b0IQRM/KLERYOQdmWP5jZr7 EBgZI/PatymfhEEoaCUOug5qpEUnkuxHlgtSF4ps2EfqPuSpyf+c5Me5b9xpktb9PnTy pLdg== X-Gm-Message-State: AKwxyteieb35oC1k/RTLu6pKyC4omiQC+z0xcyiEr5+ERyi3iYJq73z4 7OMf57D1hMPocLSiDI/kRr42Aw== X-Google-Smtp-Source: AH8x224FHQsJM1XfuHkONerhDzn2qIuHykGPTPbRGIq/etPw9oEQzYSFW9e48EvYee1psIPjr9pHlg== X-Received: by 10.80.173.174 with SMTP id a43mr45497596edd.295.1517606245942; Fri, 02 Feb 2018 13:17:25 -0800 (PST) Received: from asommer-mac.local ([2001:4c50:28e:fe00:311b:b046:3e9a:9d4e]) by smtp.googlemail.com with ESMTPSA id n2sm2522334edl.74.2018.02.02.13.17.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 13:17:24 -0800 (PST) From: Andreas Sommer Subject: Audit of NPM/NodeJS module dependencies To: freebsd-ports@freebsd.org Message-ID: Date: Fri, 2 Feb 2018 22:17:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Thunderbird/58.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 21:17:28 -0000 Hi everyone, npm/node modules creeping into ports was already discussed in the forums[0] and cannot be a viable solution for tracking hundreds+ JavaScript dependencies. Nevertheless, I believe that usage of node is very popular – including use of React etc. for frontends in my company. If you build your software in the freebsd-ports/poudriere/pkgng style, there is no built-in way to detect vulnerabilities of npm modules since they are not tracked as pkg dependencies and therefore also not listed in the VuXML database, thus not checked by `pkg audit`. I'd like to ask this list if there is at all interest in solving this problem (for FreeBSD Ports) and how to nicely integrate it without having to register every module as port. Ideas to tackle this: A) I've already ported OWASP's DependencyCheck tool[1] locally and can immediately open a PR to allow everyone to make use of it. The tool uses several online databases to detect vulnerabilities within a project's source code (namely package.json which lists those module dependencies). It can create both human and machine-readable reports and optionally `exit 1` if the vulnerability score is over a certain threshold (in other words: it's quite versatile). Alternatives include tools like `nsp` which I believe uses a database that OWASP DependencyCheck already covers among others, so I opted for a multi-database tool to cover as many vulnerabilities as possible. B) My ideas for a solution: B1) Run DependencyCheck during the `fetch` phase (only one in poudriere that has Internet access) and spit out warnings or errors that we can react to (e.g. send alarms from CI) B2) Run DependencyCheck separately on each port and if vulnerabilities are found, mark that project's latest release version as vulnerable in a custom VuXML file. Patch `pkg` to support multiple `VULNXML_SITE` entries (official one for ports + the one for npm modules). Then production systems' `pkg audit` would detect when packages are vulnerable as usual. That would require an automated system (like portscout) to check all ports regularly and write VuXML entries. I guess false positives may occur, requiring a blacklist file and way to remove the false entries. This solution could also work with just one VuXML file – the official one. Introducing a second one has the advantage of making this feature optional (for the start), not breaking existing systems. B3) Both, since B1 is helpful for developers and B2 is helpful for sysadmins. Also, B1 would only error when building ports which *already have* vulnerable dependencies, but obviously dependencies might get a CVE *after* being installed as package, so B2 is needed to run the vulnerability check regularly. B4) Similar to B2: include npm module dependencies in package description (+MANIFEST:desc or new field) and then create some automated service to check those dependencies regularly. This has the advantage of not requiring fetch of the source code, so it's much easier to build an automated checker that quickly runs over all ports. *) Looking forward to see if there is interest and great ideas! I also want to hear if someone has concerns and objections to solving this at the ports/package level. Whatever the outcome is, I will implement *something* within my company – but an open source solution would be preferable. Cheers, Andreas [0] https://forums.freebsd.org/threads/56791/#post-323273 (NodeJS modules creeping into ports) [1] https://github.com/jeremylong/DependencyCheck (OWASP Dependency Check)