Secure Software Development Lifecycle

This time I will introduce you to one of the ways develop secure, robust and high quality software in a pragmatic and agile manager.

There are a few prerequisites to have effective software development.

Firstly, everybody should understand why you develop what you develop. Secondly, every team member should strive to be a better engineer and person by embracing Mastery, Autonomy and Purpose approach.

Thirdly, the team should have short term plan and long term road map with vision.

Why I put high emphasize on the prerequisites? Because everybody in your team is responsible for the Secure Software Development Life Cycle (SSDLC).

Let’s start.

0. You have, to same extend, clear and doable requirements.

  1. Split requirements into epics and user stories (US). I am using Jira for the last many years with requirements put on Confluence.
  2. Make a high level planning using grooming technics and plan user stories into sprints.
  3. Plan a concrete sprint and assign user stories to concrete team members. The person who is assigned to the US is responsible for it execution, but it does not mean he needs to do it end-to-end.
  4. Create technical tasks for every US and each US should have a technical specification which contains at least the following items: testing strategy, implementation details (that includes peaces of code if necessary and UML diagrams), security analysis (as a minimum reviews of OWASP TOP 10 items), deployment plan, monitoring and backward compatibility analysis etc.
  5. Two team members, at least one is Senior, should review the technical specification and reach the final agreement with the creator of tech spec.
  6. After technical specification is agreed and approved all technical tasks updated or created to reflect the plan made in tech spec.
  7. The tasks are assigned to the right people, tasks are aligned towards Sprint plan and capacity of team members. Tasks receive estimated and completed-by-dates.
  8. Using TDD and BDD technics the features are implemented according to the tech spec. If there are changes during the implementation, they should be reflected in the tech spec, which should be watched by the tech spec reviewers.
  9. After the code is complete the Pull Requests should be created to assigned to the tech spec reviewers or component owners which do code review considering all tech spec items, performance and security aspects are clearly should be forgotten.
  10. When all major pull request’s notes are fixed and merge is done by the component owner.
  11. Documentation and release notes are updated by the responsible for the task Engineer.
  12. When all subtasks/technical tasks are done the main User Story is updated, so Product Owner may pull the code to an environment and do a self demo. The US is marked as DONE.

I don’t pretend that this is the most precise plan or list, so I would be happy to clarify the articles with your help. So Comment please!

Building the future, team visibility advocate

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store