/cydig-compliance-action

Primary LanguageTypeScript

OP Compliance Dashboard

Timestamp

threatModelingDate
numberOfReviewers
scaTool
sastTool
secureScore
allowedLocationPolicy
pentestDate
numberOfDeployedVMs
numberOfExposedSecrets
codeQualityTool
usersInProduction
userAccessToCode

CyDig Compliance Action

This repository contains a action with compliance controls.

Compliance Controls

The compliance controls that are currently available are listed below.

  • Number of reviewers on a pull request
  • Number of exposed secrets
  • Date of latest threat modeling
  • Date of latest penetration test
  • Implemented SCA tool
  • Implemented SAST tool

Development on already existing or new control.

  1. To start development, create a branch named feature/your-branch-name.

  2. Run the command below from the root.

npm install

By first running npm install in the root you get the linting and format dependencies downloaded. To enable so that every time you make a commit, a pre-hook will run to validate the rules read more here. To fix format warnings manually run the following command from the root:

npm run format:write
  1. If you are developing a new control, create a new folder for your control in the src folder.
  2. Start developing. To compile your code, run the following command:
npm run build
  1. To run the tests, run the following command:
npm run test

To generated test results in a XML-file, run the following command:

npm run testScript

  1. If necessary, add input parameter in action.yml, if it is needed for the control.

  2. When pushing the code the repository the workflow will build and push your code to the repository.

For more information about developing in the CyDig project, please go to the Wiki

Creating a release for the action

At cydig, we follow Semantic Versioning for our action releases. Practically, this means that when you're developing and creating a pull request (PR), you can assign one of three labels to the PR: Major, Minor, or Patch. These labels correspond to version numbers in the format vX.Y.Z, where X is the major version, Y is the minor version, and Z is the patch version.For example, if you add the "Patch" label to your PR, and it's approved and merged, a workflow will automatically run to create a release for the action. Here's an illustration of how the version number would change before and after the PR:

  • Version before PR: v1.0.1
  • Version after PR: v1.0.2