--- layout: markdown_page title: Keeping secure coding knowledge fresh in development --- ## On this page {:.no_toc} - TOC {:toc} # Secure Coding Training Guidelines It is essential that all developers are aware of secure coding best practices and refresh this knowledge periodically. # Why * It reduces the chances of security issues being introduced into GitLab. * Some developers want to learn secure coding as a part of their ongoing learning. * It may help to make customers and auditors more comfortable with the security of our product. # Background * [Secure coding training](https://about.gitlab.com/handbook/engineering/security/secure-coding-training.html) was done in late July of 2019. * Secure coding is an [onboarding task](https://gitlab.com/gitlab-com/people-group/employment-templates-2/blob/master/.gitlab/issue_templates/onboarding_tasks/department_development.md) for new developers. # What challenges does this address? * We do not track who has taken the training to gauge our security risk. * We do not encourage developers to do the training if they have not previously taken the course. * We do not have a plan to motivate GitLabbers to refresh their knowledge of secure coding periodically. # Considerations * We want to _encourage_ GitLabbers to take this training and periodically refresh their knowledge of it because they believe it is relevant to them and the company. We do not want to _force_ it on them. * We want to track how many GitLabbers have taken the training / refreshed their knowledge on it to encourage full participation; however, we do not want to make it feel punitive to them if they have not yet done so. * We want to avoid burdening engineers with the tracking of these activities. # The Plan ## February 2020 * Create an issue and list each manager and the number of direct reports that are engineers in a table: [6406](https://gitlab.com/gitlab-com/www-gitlab-com/issues/6406) * Ask managers to update the issue with how many engineers on each team have indicated that have taken the training. * Ask managers to encourage those who have not taken the training to do so. We chose to have engineering managers track this for their teams vs. using the [acknowledgment process](https://about.gitlab.com/handbook/communication/#acknowledgement-receipts-ack) as it is believed it will cause it to be better received. ## April 2020 * Create an new issue and list each manager and the number of direct reports that are engineers in a table. * Create an OKR for Q2 to have >=90% of engineers acknowledge that they have taken the secure training class by the end of Q2 (end of July). ## July 2020 * Ask managers to update the table with the number of direct reports that have taken the training. * Update OKR based on results. ## 2021 * Repeat the OKR / tracking process to take into account new engineers and those who did not take the training in 2020. * Create a short refresher course on secure coding for those who took the full course previously.