Find optimal GitHub security settings

[EvgeniiaVak]

We need to ensure our code base is safe. It's hard to do something irreversibly, because lots of people (well... I think 3 atm) have local copies of almost all the code at all times, but as we grow that might miss some malicious PR, especially if the hackers team up.
Initially, we only set up the main branch protection rules, maybe we need something more? How do we add new members? What is the right process of vetting 3rd party apps? Etc.

[EvgeniiaVak]

Example of a 3rd party apps that could potentially be problematic - Github Bot, or Discord integration bot. The question is how safe is it to add those things? Currently we don't have any secrets (for example env. vars for deployment) setup, but we might have in the future. Given that the apps have access to the settings, do they have access to the secrets? Do the apps have more permissions than the member default?

I don't like that there is no open source for the Telegram bot (@RepServ or did I miss it somewhere?). @ArthurQuantize is there source code for Discord bot?

I don't like how much permissions this app asks for

[RepServ]

@EvgeniiaVak very important issue you've raised. I'll check for more details and get back please. Thanks...

[RepServ]

@EvgeniiaVak very important issue you've raised. I'll check for more details and get back please. Thanks...

From my checks it's not open source. That's risky, especially if it can access github secrets. I've removed it's link to DeXter github account. Please go ahead and revoke access.

NB:
I couldn't find anything on the discord plugin either.

[EvgeniiaVak]

I revoked the telegram bot application access:

->

[EvgeniiaVak]

I'm going to leave discord on because it's not an app, but a webhook for events, so it can only see the events stream, but not settings or something like that.

[ArthurQuantize]

That's good as it's so useful! As long as we can limit permissions correctly it should be fine then 👍

…

On Wed, 9 Aug 2023, 07:08 EvgeniiaVak, ***@***.***> wrote: I'm going to leave discord on because it's not an app, but a webhook for events, so it can only see the events stream, but not settings or something like that. [image: Screenshot 2023-08-09 at 09 07 59] <https://user-images.githubusercontent.com/27793901/259302100-78f36225-a01b-447b-a587-7c496f38366c.png> — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCVPZDXXE6INEZZDMMN4G3XUMLMHANCNFSM6AAAAAA2ABW2NE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RepServ]

Great!

…

On Wed, 9 Aug 2023, 06:04 EvgeniiaVak, ***@***.***> wrote: I revoked the telegram bot application access: [image: Screenshot 2023-08-09 at 09 01 19] <https://user-images.githubusercontent.com/27793901/259301384-267cc934-aa5e-4789-98e9-41367e094b24.png> -> [image: Screenshot 2023-08-09 at 09 02 06] <https://user-images.githubusercontent.com/27793901/259301412-1edc4726-b833-4b47-85d0-c1539bcddabf.png> — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBHM3D3VULCUWCVOXFFAQYTXUMK4VANCNFSM6AAAAAA2ABW2NE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fliebenberg]

We need to finalise this issue as it relates to new contributors to the project. I would suggest we create roles that we can assign people to as they gain trust.
Contributor -> members who can contribute to issues, fork the project and make PRs but cannot approve PRs or merge.
Developer -> members who can approve PRs
Admin _> can change member status and add new members

Not a github expert, but think this can be done. @EvgeniiaVak keen to hear you opinion since you have been "running" github very professionally for us up to now.
Keen to hear other opinions so we can set this up. I expect more developers to start joining so it will help to get the process sorted.

[EvgeniiaVak]

In my opinion, it's not an urgent issue, anyone in the world can make a fork already (so nobody is blocked and anyone can work on issues). The right to approve requests and merge needs to be earned... somehow... I don't know how though. If we just grant approve-and-merge rights to anyone who asks, that is good for newcomers to feel welcome and that's good, but it's also risky.

I like the Contributor / Developer (I think it's Maintainer in GitHub terms) / Admin suggestion. This will require some time to get it right though. As we not only want to define the roles, we need to set up a system on how to decide who can gain any of these roles and how.

The The good place to start - https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization - for a person (a member, but not an owner) to gain those roles (technically) we need to create teams and assign people to those teams, also a bit of hustle. If possible, let's postpone this one till after the MVP.

[yuliaSharabi]

I believe we are lucking a procedure with best practices for PR review, PR approvals and acsess control (roles).
We can start with having the read.me called "PR guidlies" and seperate it to phases - review, approve, who can submit/approve etc..
I am willing to start this task. @EvgeniiaVak .
There are more to be done, security wise.
Use GitHub's Security Features: such as Dependabot for automatic dependency updates, Code Scanning for finding vulnerabilities, and Secret Scanning

Usfull resources:
securing-your-repository,
securing-accounts.

[EvgeniiaVak]

We have some procedure around PRs and autodeploy (PR with update to readme is welcome, also maybe @yuliaSharabi you have some suggestion to edit this procedure):

• deployment for mainnet happens automatically from main branch (for testnet from the PR previews, links are generated in each PR)
• main branch can be updated only via a PR
• anyone can create a fork and make a PR, only org owners and developers can create a branch in this repo and make a PR
• anyone can leave comments in PRs
• org owners, developers and testers can review PRs (leave approvals, require changes)
• [WIP] for a PR to be able get merged, it needs at least 2 approvals, and at least 1 approval from a code owner (do not confuse with org owners)
• [WIP] code owners are specified in CODEOWNERS file (add CODEOWNERS file #214), currently it's developers for all the code, and testers for e2e folder

I'm not sure who specifically can merge (click the merge button) a PR, after it gets at least 2 approvals and at least 1 approval from a code owner, maybe only org owners (aka repo admins in this case), or maybe developers and testers can do it too.

[EvgeniiaVak]

@yuliaSharabi here is the updated https://github.com/DeXter-on-Radix/website/settings/security_analysis , let me know if you think we should add/enable anything else

[EvgeniiaVak]

Closing this, because the security discussion moved to Discord (restricted access channel)