Skip to main content

2. People

  • Empowering developers is key to cybersecurity. Once a skilled developer fully embraces security as a primary responsibility, huge progress can be observed.
  • Given security is often neglected by developers, this takes time and iterations.
  • First, developers shall be educated practically, through a hands-on approach, so as to become aware of the impact of development practices on software security.
  • Then, they shall be involved in the security improvement through security stories that can be added in the development backlog and discussed by the team.
  • Eventually, at least a few members of the development team shall act as security champions, and keep improving security practices. Ideally, every developer shall feel responsible for security.
  • Peer review is a key practice to for development security. It has several benefits:
    • It is probably the most effective way to transmit good practices and knowledge.
    • When done seriously, it strongly diminishes the probability of letting a flaw in the code (if the probability is random for each developer at a rate of 10%, then with one reviewer the probability fall to 1%, 0.1% with 2 reviewers).
    • It is an effective mitigation against the risk of rogue code inclusion by an attacker that succeeded to hack a developer's workstation.
    • It also improves code quality and readability.
    • It facilitates maintainability, as more than one person has understood each single line of code.
    • It can be used to implement separation of duties, with different developers in charge of coding and in charge of integration.
  • To maximize productivity, peer review shall occur after automatic reviews (SAST/DAST tools).
  • Peer review organization shall be automated, which is very easy with tools like Github or Gitlab.
  • The number of reviewer shall depend on the sensitivity of code. For normal code, 1 reviewer is reasonable. For sensitive code (e.g. for a component managing access control), 2 reviewers is a must.
  • The choice of reviewer shall be left to the developers, but with team/management control. Any developer shall be able to perform an additional review if he/she deems it valuable.
  • OWASP provides a very good guide on secure code review: https://owasp.org/www-project-code-review-guide/
  • Awareness sessions shall be organized regularly, preferrably with a hands-on approach.
  • Tools like Google Gruyere (https://google-gruyere.appspot.com/) are well fitted to organize a 2-hour session with 4 to 10 persons.
  • 1 or 2 days advanced training sessions can cover more theoretical knowledge, and in-depth reviews on flawed code.
  • The handling of credentials (passwords, keys) by humans is a process that is difficult to handle properly.
    • Users shall be educated to use systematically a trusted credential manager (Keepass is a popular choice), and always generate passwords randomly with a proper complexity (at least 100 bits, >128 bits recommended).
    • Developers shall understand why they should never (ever) commit a secret in git, and how to handle such errors (when possible by revoking the credential, making the secret useless).
    • Credentials that can be handled automatically without need of human knowledge shall be preferred. This is clearly the way to go, with ultimately users never manipulating credentials.
    • Credential sharing is often necessary. This can be done through shared credential stores (e.g. with a shared Keepass store).
    • Credential rotation is especially difficult in practice, and often never done. The best way to achieve proper rotation is to use include this requirement at design stage.