[BB pr#3] KIT-2 Configure Veracode

[coveobot]

Pull request 🔀 created by @ThibodeauJF on 2020-04-02 21:50
Last updated on 2020-04-04 00:05
Original Bitbucket pull request id: 3

Participants:

• @btaillon (reviewer) ✔️
• @olamothe (reviewer) ✔️
• @samisayegh (reviewer) ✔️
• @ThibodeauJF

Source: Commit 6ed10a112e4b on branch KIT-2> Destination: https://bitbucket.org/coveord/ui-kit/commits/ca93cceee906 on branch KIT-3
Merge commit: https://github.com/None/commit/ba9337bab941

State: MERGED

I’m zipping headless inside the veracode folder. Seems a .zip of the veracode folder is sent to Veracode. Wonder if that’s the correct thing 🤔

https://analysiscenter.veracode.com/auth/index.jsp#SandboxView:36177:318526:1975267

https://coveord.atlassian.net/browse/KIT-2

‌

[coveobot]

@olamothe commented on 2020-04-03 12:44

Seems to be okay. Here’s the veracode documentation : https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/AM8PAkQKwsHbNYXy2VeX5Q

‌

You can make sure we’re following their documentation on how to package.

[coveobot]

@olamothe commented on 2020-04-03 12:45

Outdated location: line 46 of .deployment.config.json

I’d set veracode.zip explicitely. And then, we’ll need to make sure we bundle everything we need inside that folder.

‌

Just so veracode does not start scanning random stuff in the project.

[coveobot]

@olamothe approved ✔️ the pull request on 2020-04-03 12:46

[coveobot]

@samisayegh commented on 2020-04-03 13:37

Outdated location: line 19 of Jenkinsfile

Could it be tidier to move the veracode stage to the deployment package docker to avoid having two branch checks?

[coveobot]

@samisayegh approved ✔️ the pull request on 2020-04-03 13:37

[coveobot]

@btaillon commented on 2020-04-03 17:13

Location: line 6 of Jenkinsfile

node:13 appears to currently be an alias for node:13.12.0-stretch (https://hub.docker.com/_/node/) which has 624 open vulnerabilities according to Snyk (https://snyk.io/test/docker/node%3A13.12.0-stretch).

Given that this is only for the purpose of building and packaging the project, would it be worth using a more explicit node version with less open vulnerabilities?

Also, would it be advantageous to use alpine instead of debian?

I’m asking those as questions because I’m not very familiar with whether there are security risks involved in building and packaging an application.

[coveobot]

@btaillon approved ✔️ the pull request on 2020-04-03 17:14

[coveobot]

@ThibodeauJF commented on 2020-04-03 18:41

Location: line 6 of Jenkinsfile

I’ll answer the same thing as the member from the security team on a previous PR:

Hum, node:12 (here the more recent 13) is the official image (https://hub.docker.com/_/node). A lot of things needs to be broken before this image gets compromised.

I wouldn’t worry about this