---
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.