Skip to content

Commit f47c5c4

Browse files
authored
Merge pull request #3712 from DefectDojo/release/1.12.0
Release: Merge release into master from: release/1.12.0
2 parents 3cd650c + 9badf64 commit f47c5c4

File tree

281 files changed

+30534
-3233
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

281 files changed

+30534
-3233
lines changed

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
1-
**Descriptions**
1+
**Description**
22

3-
Describe the feature / bug fix implemented by this PR
3+
Describe the feature / bug fix implemented by this PR.
4+
If this is a new parser, [the parser guide](../../doc/guide_to_parser_writing.md) may be worth (re)reading.
45

56
**Test results**
67

@@ -55,12 +56,12 @@ In case of conflict:
5556
git rebase --continue
5657
```
5758

58-
When everything's fine on your local branch, force push to your `myOrigin` remote:
59+
When everything's fine on your local branch, force push to your `myOrigin` remote:
5960
```
6061
git push myOrigin --force-with-lease
6162
```
6263

63-
To cancel everything:
64+
To cancel everything:
6465
```
6566
git rebase --abort
6667
```
@@ -74,7 +75,7 @@ git rebase -i origin/dev
7475
- Replace `pick` by `reword` on the first commit if you want to change the commit message
7576
- Save the file and quit your editor
7677

77-
Force push to your `myOrigin` remote:
78+
Force push to your `myOrigin` remote:
7879
```
7980
git push myOrigin --force-with-lease
8081
```

.github/release-drafter.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,8 @@ categories:
3434
labels:
3535
- 'dependencies'
3636
- 'maintenance'
37+
exclude-labels:
38+
- 'skip-changelog'
3739
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
3840
template: |
3941
## Changes since $PREVIOUS_TAG

.github/workflows/cancel-outdated-workflow-runs.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ jobs:
1313
runs-on: ubuntu-latest
1414
timeout-minutes: 3
1515
steps:
16-
- uses: styfle/cancel-workflow-action@0.6.0
16+
- uses: styfle/cancel-workflow-action@0.7.0
1717
with:
1818
workflow_id: 'integration-tests.yml,k8s-testing.yml,unit-tests.yml'
1919
access_token: ${{ github.token }}

.github/workflows/release-drafter.yml

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,13 @@ name: Release Drafter
22

33
on:
44
workflow_dispatch:
5+
inputs:
6+
version:
7+
description: |
8+
The version to be associated with the GitHub release that's created or updated.
9+
This will override any version calculated by the release-drafter.
10+
required: false
11+
512
push:
613
# branches to consider in the event; optional, defaults to all
714
branches:
@@ -13,5 +20,7 @@ jobs:
1320
runs-on: ubuntu-latest
1421
steps:
1522
- uses: release-drafter/[email protected]
23+
with:
24+
version: ${{github.event.inputs.version}}
1625
env:
1726
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

BRANCHING-MODEL.md

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,18 +1,18 @@
11
# Introduction
2-
This section describes
3-
- how branches are handled
4-
- defectdojo release cycle
2+
The DefectDojo team aims to release at least once a month, on the last Tuesday.
3+
Bugfix or security releases can come at any time.
54

6-
Please be careful to submit your pull requests to the correct branch:
7-
- bugfix: latest "release/a.b.x" branch (+ merge using a separate PR against the dev branch)
8-
- evolutions: dev branch
5+
In doubt, GitHub Actions are the source of truth. The releases are semi-automated right now, with a DefectDojo maintainer proceeding with each major step in the release. The steps for a regular release are:
6+
1. Create the release branch from `dev` and prepare a PR against `master` ([Details](.github/workflows/new-release-pr.yml))
7+
--> A maintainer verifies and manually merges the PR
8+
2. Tag, issue draft release and docker build+push ([Details](.github/workflows/new-release-tag-docker.yml))
9+
--> A maintainer massages the release-drafter notes and publishes the release
10+
3. A PR to merge `master` back to `dev` is created to re-align the branches ([details](.github/workflows/new-release-master-into-dev.yml))
911

10-
If in doubt please use dev branch.
12+
# Security releases
13+
PRs that relate to security issues are done through [Security advisories](https://github.com/DefectDojo/django-DefectDojo/security/advisories) which provide a way to work privately on code without prematurely disclosing vulnerabilities.
1114

1215
# Release and hotfix model
1316
![Schemas](doc/branching_model.png)
1417

15-
16-
Diagrams created with https://www.planttext.com/
17-
18-
This model is inspired by https://nvie.com/posts/a-successful-git-branching-model/ with the feature branch being made in each contributor repository.
18+
Diagrams created with [plantUML](https://plantuml.com). Find a web-based editor for PlantUML at https://www.planttext.com.

CONTRIBUTING.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,10 @@ Bugs that do not have this information will be closed.
1212

1313
Here are a few things to keep in mind when making changes to DefectDojo.
1414

15+
## Writing a new parser
16+
17+
Please see [this file](doc/guide_to_parser_writing.md) for guidance on how to write a parser.
18+
1519
## Modifying DefectDojo and Testing
1620

1721
Please use [these test scripts](./tests) to test your changes. These are the scripts we run in our [integration tests](DOCKER.md#run-the-tests-with-docker).

components/package.json

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"name": "DefectDojo",
3-
"version": "1.11.1",
3+
"version": "1.12.0",
44
"dependencies": {
55
"JUMFlot": "jumjum123/JUMFlot#*",
66
"bootstrap": "^3.4.0",
@@ -35,7 +35,7 @@
3535
"metismenu": "~3.0.6",
3636
"moment": "^2.29.1",
3737
"morris.js": "morrisjs/morris.js",
38-
"pdfmake": "^0.1.69",
38+
"pdfmake": "^0.1.70",
3939
"startbootstrap-sb-admin-2": "1.0.7"
4040
},
4141
"engines": {

components/yarn.lock

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -828,10 +828,10 @@ pdfkit@>=0.8.1, pdfkit@^0.11.0:
828828
linebreak "^1.0.2"
829829
png-js "^1.0.0"
830830

831-
pdfmake@^0.1.69:
832-
version "0.1.69"
833-
resolved "https://registry.yarnpkg.com/pdfmake/-/pdfmake-0.1.69.tgz#e4c6dcc9b058ab7a639061e295518a8fd196097d"
834-
integrity sha512-XGMtTpbgEwXsa9DcuKhMowOPVJ+8cnGuJz7LV/bE5pnMmxBXAlMGgidQVyEfEUPFywCU2Y/4xibeX1vEm0hd7g==
831+
pdfmake@^0.1.70:
832+
version "0.1.70"
833+
resolved "https://registry.yarnpkg.com/pdfmake/-/pdfmake-0.1.70.tgz#b5102799deef264defa675dbb2dbf12ad49a9bae"
834+
integrity sha512-xPhkblaQ71U97qhRTPj/1HknAHHFZ3cPRmRdrqEWD2xXBcEjEM3Yw0MIjML8DRy9Dt9n6QRjHVf662f0eLtd7Q==
835835
dependencies:
836836
iconv-lite "^0.6.2"
837837
linebreak "^1.0.2"

doc/branching_model.puml

Lines changed: 15 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -1,95 +1,46 @@
11
@startuml
22
!pragma teoz true
33

4-
== Initial release ==
4+
== Monthly release ==
55
participant "Dev branch" as devbranch order 10 #LightBlue
66
participant "Release branch" as rlsbranch order 20 #YellowGreen
77
participant "Master branch" as master order 30 #99FF99
8-
participant "Maintainance branch" as maintainbranch order 40 #YellowGreen
9-
participant "Hotfix branch" as hotbranch order 40 #DarkSalmon
8+
'participant "Maintenance branch" as maintainbranch order 40 #YellowGreen
109

1110
{startrc} devbranch -> rlsbranch ++ #YellowGreen: Create branch "release/1.0.0"
1211

13-
14-
note left of devbranch
15-
Evolutions
16-
end note
17-
18-
19-
note right of rlsbranch
20-
Bug fixes
21-
end note
22-
23-
rlsbranch --> devbranch: Contributors merge bug fixes using a separate PR
24-
25-
26-
2712
rlsbranch -> master: Merge
2813
note right of master
2914
Official release
3015
- Tag "1.0.0"
3116
- Push "1.0.0" to DockerHub
3217
end note
3318

34-
== Release maintainance ==
35-
master -> maintainbranch ++ #YellowGreen: Create branch "release/1.0.x"
36-
37-
note right of maintainbranch
38-
Bug fixes
39-
end note
40-
41-
maintainbranch --> devbranch: Contributors merge bug fixes using a separate PR
19+
master --> devbranch: Merge master back to dev to re-align
4220

21+
... ...
4322

44-
maintainbranch -> master: Merge
45-
note right of master
23+
== Maintenance/security releases ==
24+
master -> rlsbranch ++ #YellowGreen: Create branch "release/1.0.x"
25+
note left of rlsbranch
4626
Official release
4727
- Tag "1.0.1"
4828
- Push "1.0.1" to DockerHub
4929
end note
30+
rlsbranch -> master: Merge
31+
master --> devbranch: Merge
5032

51-
maintainbranch --> devbranch: Contributors merge bug fixes using a separate PR
33+
... ...
5234

53-
maintainbranch -> master: Merge
54-
note right of master
35+
master -> rlsbranch ++ #YellowGreen: Create branch "release/1.0.x"
36+
note left of rlsbranch
5537
Official release
5638
- Tag "1.0.2"
5739
- Push "1.0.2" to DockerHub
5840
end note
59-
60-
== Hotfix ==
61-
62-
master -> hotbranch ++ #DarkSalmon: Create short-lived fix branch "hotfix/1.0.3"
63-
note left
64-
If in need of an urgent fix
65-
and PR have already been merged to release/1.0.x
66-
since 1.0.2 release
67-
end note
68-
69-
note right of hotbranch
70-
Severe bug
71-
to be corrected
72-
end note
73-
74-
hotbranch -> maintainbranch: Merge
75-
hotbranch -> devbranch --: Merge (Optional)
76-
hotbranch -> master --: Merge
77-
note right of master
78-
Official release
79-
- Tag "1.0.3"
80-
- Push "1.0.3" to DockerHub
81-
end note
82-
83-
== Next release ==
84-
{endrc} devbranch -> rlsbranch: Create branch\n "release/1.1.0"
85-
note left of devbranch
86-
Or release/2.0.0 in case of
87-
major breaking change
88-
end note
89-
41+
rlsbranch -> master: Merge
42+
master --> devbranch: Merge
9043

9144
... ...
92-
{startrc} <-> {endrc}: \n4-8 weeks
93-
9445

95-
@enduml
46+
@enduml

doc/guide_to_parser_writing.md

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
# How to write a DefectDojo parser
2+
3+
> All commands assume that you're located at the root of the django-DefectDojo cloned repo.
4+
5+
## Pre-requisites
6+
- You have forked https://github.com/DefectDojo/django-DefectDojo and cloned locally.
7+
- Checkout `dev` and make sure you're up to date with the latest changes.
8+
- It's advised that you create a dedicated branch for your development, such as `git checkout -b parser-name` yet that's up to you.
9+
10+
It is probably easier to use the docker-compose stack (and benefit from the hot-reload capbility for uWSGI).
11+
Set up your environment to use the dev or ptvsd environment, such as:
12+
13+
`$ docker/setEnv.sh dev`
14+
or
15+
`$ docker/setEnv.sh ptvsd` (allows to set breakpoints in uWSGI)
16+
17+
Please have a look at [DOCKER.md](../DOCKER.md) for more details.
18+
19+
### docker images
20+
You'd want to build your docker images locally, and eventually pass in your local user's `uid` to be able to write to the image (handy for database migration files). Assuming your user's `uid` is `1000`, then:
21+
22+
`$ docker-compose build --build-arg uid=1000`
23+
24+
## Which files do you need to modify?
25+
26+
| File | Purpose
27+
|------- |--------
28+
|`dojo/fixtures/test_type.json` | Django fixture for the type of scan. Take the next available integer if you intend to push upstream. If you're planning to use only in your own fork, you could jump ahead by 1000 to avoid any potential conflicts.
29+
|`dojo/templates/dojo/import_scan_results.html` | Add the scan to the array presented in the drop-down box
30+
|`dojo/tools/<parser_dir>/__init__.py` | Empty file for class initialization
31+
|`dojo/tools/<parser_dir>/parser.py` | The meat. This is where you write your actual parser
32+
|`dojo/unittests/scans/<parser_dir>/{many_vulns,no_vuln,one_vuln}.json` | Sample files containing meaningful data for unit tests. The minimal set.
33+
|`dojo/unittests/test_<parser_dir>_parser.py` | The unittest class, holding unit tests definitions
34+
|`dojo/tools/factory.py` | Import there your new parser class and add it to the long "if/else" statement
35+
36+
## Things to pay attention to
37+
38+
Parsers may have many fields, out of which many of them may be optional.
39+
40+
Always make sure you include checks to avoid potential `KeyError` errors (e.g. field does not exist), for those fields you are not absolutely certain will always be in file that will get uploaded. These translate to 500 error, and do not look good.
41+
42+
## Unit tests
43+
44+
Each parser must have unit tests, at least to test for 0 vuln, 1 vuln and many vulns. You can take a look at how other parsers have them for starters. The more quality tests, the better.
45+
46+
### Test database
47+
To test your unit tests locally, you first need to grant some rights. Get your MySQL root password from the docker-compose logs, login as root and issue the following commands:
48+
49+
```
50+
MYSQL> grant all privileges on test_defectdojo.* to defectdojo@'%';
51+
MYSQL> flush privileges;
52+
```
53+
54+
### Run your tests
55+
56+
This local command will launch the unit test for your new parser
57+
58+
`$ docker-compose exec uwsgi bash -c 'python manage.py test dojo.unittests.<your_unittest_py_file>.<main_class_name> -v2'`
59+
60+
Example for the blackduck hub parser:
61+
62+
`$ docker-compose exec uwsgi bash -c 'python manage.py test dojo.unittests.test_blackduck_csv_parser.TestBlackduckHubParser -v2'`
63+
64+
> If you want to run all unit tests, simply run `$ docker-compose exec uwsgi bash -c 'python manage.py test dojo.unittests -v2'`
65+
66+
## Other files that could be involved
67+
68+
### Change to the model
69+
In the event where you'd have to change the model, e.g. to increase a database column size to accomodate a longer string of data to be saved
70+
* Change what you need in `dojo/models.py`
71+
* Create a new migration file in dojo/db_migrations by running and including as part of your PR
72+
73+
`$ docker-compose exec uwsgi bash -c 'python manage.py makemigrations -v2'`
74+
75+
### Accept a different type of file to upload
76+
If you want to be able to accept a new type of file for your parser, take a look at `dojo/forms.py` around line 436 (at the time of this writing) or locate the 2 places (for import and re-import) where you find the string `attrs={"accept":`.
77+
78+
Formats currently accepted: .xml, .csv, .nessus, .json, .html, .js, .zip.
79+
80+
### A need for more than just the parser.py
81+
82+
Of course, nothing prevents you from having more files than the `parser.py` file. It's python :-)
83+
84+
## Example PRs
85+
86+
If you want to take a look at previous parsers that are now part of DefectDojo, take a look at https://github.com/DefectDojo/django-DefectDojo/pulls?q=is%3Apr+label%3A%22import+scans%22+
87+
88+
## Update the readthedocs documentation
89+
90+
The DefectDojo official documentation lives in another repository, https://github.com/DefectDojo/documentation
91+
92+
Please update the `docs/integration.rst` with the details of your new parser and create a PR in that repo. Reference the PR in the main DefectDojo repository to establish an automatic link between the two.

0 commit comments

Comments
 (0)