0

How do you ensure on a high level that developed software is secure and compliant.

We want to introduce a service checklist that will list each item, including "Security and Compliance" section.

It will have things/requirements like:

  • No plain-text secrets are present in the source code.
  • Any sensitive data can only be accessed after authentication/authorization, with the principle of least privilege in mind.
  • Any production credentials are strong and unique.

etc

The problem is that I realized the highest assurance you get asking more questions i.e hence the OWASP Application Security Verification Standard with 68 pages.

How do you balance this?

Question is:

Any standard? Checklists available online? Any tips on approach?

What core requirements do come to your mind to check the software for security and compliance in agile development?

As I said I think it is tricky, since we dont want to have it too big, nor too small (i.e is software secure? yes/no)

I hope you get my point.

4
  • How experienced are you with running the hardware security modules needed to properly store nuclear launch codes? My point of course is simple: there isn't one checklist. It isn't about "Secure" or "not secure". It's about "Secure enough for me". The general concept you are looking for is threat modeling. – Conor Mancone Feb 28 '20 at 10:03
  • Well, I am looking for the most common, popular, general checklist or areas to check for a typical software/SaaS company. I can imagine there are tons of them out there. Maybe somebody can share something, they created. For example I was thinking to check CIA (Confidentiality Integrity Availability) areas, but not sure about subcategories. I can than form questions for the checklist. If you have ideas where to find inspiration for question, that would be also great. I know this is a tricky question, also to have the balance of questions amount and security gain – dev Feb 28 '20 at 10:26
  • The issue isn't that this question is tricky, the issue is that a "typical software/SaaS company" doesn't exist. Every company has their own particular concerns, their own budget, their own level of resources. Two different companies will have two completely different "answers". – Conor Mancone Feb 28 '20 at 10:30
  • Thanks for your guideance. I am at point that any answer would help. High, low concerns, low/med/high budget, no sec, small sec, big sec resource. Allow me to pick from those and I will make my "own" checklist. Looking for other inspiration/guidance/ideas. – dev Feb 28 '20 at 10:37
1

Your question is a little confusing because it asks how to do this in Agile Software Development but then asks for examples of items to check. The second question seems very specific to context and since you are already looking at OWASP documents, you probably have plenty of examples. I can help with the first, but before I do, a short caveat: there is no such thing as an Agile Software Development Process. Most people, when they say this, mean they have a development process built around the Scrum Framework, so I'll assume for this answer that this applies to your team. Even if it doesn't, most of the answers wouldn't change much.

To ensure the most secure application possible, here are a few things that typical Scrum teams do:

1) Exactly what you are doing - agree upon a security standard. This should be something that all team members agree to follow.

2) Scrum has something called a Definition of Done. It is a set of quality measures that every item must meet to be considered done in a Sprint. Compliance to the security standard should be on that list.

3) Like any quality concern, security is everyone's problem. People should be discussing it in code reviews, architecture reviews, etc and it should be worked into code analysis systems and deployment processes.

4) Separation of responsibilities (between people and roles) in certain areas can contribute to a higher level of security, but it can also cause problems. Allowing only one person to have an account to a server reduces a number of people to be compromised, but also creates a bottleneck. If that bottleneck becomes an impediment to business goals, people start looking for ways around it and that opens more security risks which are harder to manage because you don't know about them. In short, security that relies strictly on rigid control is often broken, but the problems are hidden.

5) Build quality (and security) in. Better than controls, build good habits in your teams. This can't be done with a policy, this is done with culture. Leaders have to encourage people not to cut corners to make deadlines. Leaders and influencers in the organization need to visibly show that it matters to them, then your engineers need to build a habit of working in a way that is more secure. This takes months, if not years, but the pay-off is immeasurable. If you succeed here, then anything you do "checking" for security risks only has to catch human error, which is far easier and a far smaller set of problems than human negligence or neglect.

3
  • Thank you! Yes, I mixed things little bit up, sorry. Very interesting view from as I can assume experienced Scrum person. I can second that all. Let's see if there will be any other answers/views/links to references. Your answer sound like a runner up. – dev Feb 28 '20 at 15:31
  • 1
    As you look into it, take a look at lean approaches too. Most of what Agile has to say about quality and security is adapted from lean anyway. – Daniel Feb 28 '20 at 17:07
  • any thoughts on this question: security.stackexchange.com/questions/235079/… – dev Jul 23 '20 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.