• Project
• Contributing
  • Security
    • Reporting a Vulnerability
• Development
  • Technologies
  • Style Guidelines
  • Directory Layout
  • Setup
  • API Documentation
  • Unit Testing

This repository is the host to the development effort whose objective is to create automated services to further enable the CVE community in their mission.

There are many ways one can assist this project in reaching this objective.

As a developer that wants to help contribute code to the project, getting started can be as fast as choosing an issue on our board and joining our Gitter chat to talk with developers about any questions that may come up while getting oriented with the project.

The CVE project operates as several focused working groups.

The Automation Working Group focuses on technical implementation and code contribution. The group meets once a week but the meetings are not mandatory and the mailing list helps to stay in the loop on development progress as meeting notes and agendas are distributed on it. It is not mandatory to become a member of the AWG in order to contribute code.

The Quality Working Group focuses on identifying areas where CVE content, rules, guidelines, and best practices must improve to better support stakeholder use cases. This is a good place to start for sharing desired functionality with the CVE project.

The Strategic Planning Working Group focuses on the long-term strategy (1-5 years) and goals of the CVE Program; works closely with the CVE Board to determine goals and objectives and will act to achieve them. If the desired functionality falls within the SPWG's range, it might be better to become a part of this working group and assist in the future of CVE.

Whether it be submitting an issue for a feature request or a bug report, fixing a typo on some documentation, or assisting with an issue on our GitHub board, we enthusiastically welcome any contribution. If becoming a contributor to the codebase is your goal, please read our contributing guide to get started!

Please do not put vulnerability information in a GitHub issue. Please consult our SECURITY.md for specific instructions on reporting a vulnerability that exists in the CVE Services.

This project uses or depends on software from

• NodeJS https://nodejs.org/
• Express https://github.com/expressjs
• MongoDB for locally ran instances https://www.mongodb.com/
• Mongoose.js https://mongoosejs.com

This project uses the following Style Guidelines

• https://github.com/standard/standard

.
├── src                     # Source files (This is where the API resides)
├── test                    # Automated tests (This is where the API tests reside)
├── LICENSE
└── README.md               

.
├── ...
├── src                     # Source files (This is where the API resides)
│   ├── controller/         # All API logic resides here.
│   ├── model/              # All Mongoose Schemas, models, and database logic.
│   ├── middleware/         # Authentication middleware resides inside this folder. 
│   ├── routes.config.js    # This is where routes get created and get tied back to their specific controller. 
│   └── index.js            # Where everything begins.
└── ...

Before trying the AWG docker app, verify your docker setup is working properly using the "Hello World" example container with the following command:

docker run hello-world

You should see a message saying "Hello from Docker!" upon success.

Then refer to the docker README found in the repo here: https://github.com/CVEProject/cve-services/blob/dev/docker/README.md

1. Install required node modules

This assumes the latest node and npm are installed.

cd cve-services
npm install

2. Setup and start MongoDB locally

Install MongoDB locally

• https://docs.mongodb.com/manual/administration/install-community/

Download MongoDB Compass (MongoDB GUI)

• https://www.mongodb.com/download-center/compass

Create a cve_dev database in Compass. The collections will be automatically created when the API starts storing documents.

You can populate the database with test data using:

npm run populate:dev

3. Start the node application

In order to start a dev environment:

npm run start:dev

API documentation is generated using swagger-autogen which ensures that we keep the API specification up to date with any major changes to API routes. Extra information for each API route is defined as a comment in the index.js files under the respective controller and all request and response schemas are stored under the schemas folder served up by schemas.controller.

To ensure you are using the correct API specification the following endpoints can be used:

• Staging
• Production

Note: The specification file stored in GitHub will only be correct for that branch there could be differences between branches and production.

If you are developer and want to test changes to the API specification you can generate a specification in one of two ways:

1. Ideal

When you start your local development server using npm run start:dev the specification file will be generated. Subsequent changes you will need to reload the server.

If you are updating files in the schemas folder you will need to reload the server to see the changes due to the limitations of the require method.

2. Manual

You can use npm run swagger-autogen which will generate a new specification file. However, if you run npm run start:dev this will generate a specification file so you may need to adjust something if you need to test a specific thing.

This project uses the following for unit testing

• https://mochajs.org/
• https://www.chaijs.com/

In order to run the unit tests:

npm run start:test