Jordan Montgomery
8ae22b5586
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Related to, but does not resolve, #45267 Adds a 12h cooldown period such that when npm is resolving dependencies it will not resolve anything released less than 12 hours ago. This doesn't apply globally within the fleet project because some portions use yarn which #45267 will take care of however this does add it to our CI jobs and the .npmrc files for projects that use npm I was going to set this as NPM_CONFIG_MIN_RELEASE_AGE in a github EV but that won't automatically set it on every runner so leaving it in here for now As far as QA local builds and CI are both green. Tested NPM_CONFIG_MIN_RELEASE_AGE=0.5 and min-release-age=0.5(in npmrc) locally using the npm package feed https://registry.npmjs.org/-/rss to verify that recently updated packages either chose an older version OR the update was blocked if I tried to choose a newer one # Checklist for submitter ## Testing - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Enhanced npm supply-chain security by implementing package installation policies across build workflows and configuration files to exclude packages released within the last 12 hours. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45268) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->
fleet-vulnerability-dashboard
Report and track progress on fixing and prioritizing thousands of installed CVEs.
How does it work?
CVEs are detected and annotated using NVD, CVSS, EPSS, CISA KEVs, osquery, and Fleet.
Why a separate repo?
Should we move this to a subdirectory of fleetdm/confidential and have it deploy from there?
- Philosophy: Why do we use one repo?
- See also: The "broken windows effect"
- Decision: No. On 2023-07-14, we decided to keep it here so Stephan, Finn, and all other relevant folks from Fastly can access the code and collaborate.
- Update: 2023-11-06: The best thing is to move this in the ee/ directory of fleetdm/fleet. That achieves the goal of making it source available, but still paid. Logistics to enable this involve changing hosted deployments to deploy from within a nested subdirectory (something we've done before)
Cosmogony
f.k.a. "scooper"
Original raw notes and context: (private google doc since it contains competitor information: https://docs.google.com/document/d/1ByNWY6n_C-rvL75lI6jca2OniHt5FqA5_nYMf61S0pM/edit#)
Running the vulnerability dashboard with Docker.
To run a local vulnerability dashboard with docker, you can follow these instructions.
-
Clone this repo
-
Update the following ENV variables
ee/vulnerability-dashboard/docker-compose.ymlfile: -
sails_custom__fleetBaseUrl: The full URL of your Fleet instance. (e.g., https://fleet.example.com) -
sails_custom__fleetApiToken: An API token for an API-only user on your Fleet instance. -
Open the
ee/vulnerability-dashboard/folder in your terminal -
Run
docker-compose up --buildto build the vulnerability dashboard's Docker image.
The first time the vulnerability dashboard starts it will Initalize the database and run the
update-reportsscript before the server starts.
- Once the container is done building, the vulnerability dashboard will be available at http://localhost:1337
You can login with the default admin login:
Email address:
admin@example.comPassword:
abc123
How it's made
This is a Sails v1 application:
- Sails framework documentation
- Version notes / upgrading
- Deployment tips
- Community support options
- Version info: This app was originally generated on Sat Dec 10 2022 15:56:06 GMT-0600 (Central Standard Time) using Sails v1.5.3.
- This project's boilerplate is based on an expanded seed app provided by the Sails core team to make it easier for you to build on top of ready-made features like authentication, enrollment, email verification, and billing.