2

I've been looking at OWASP Application Security Verification Standard 4.0.2 for a while now, and I'm trying to understand all the checkpoints in detail.

I am not sure what exactly the author of a particular point meant. Therefore, I have a request to you to explain item 1.1.1 from section V1.1 Secure Software Development Lifecycle Requirements.

Section 1.1.1 reads Verify the use of a secure software development lifecycle that addresses security in all stages of development.

How to verify that this requirement is met by the company? What documents are required to verify that the company is complying with the SSDLC? Is it sufficient that all five phases of the SDLC are completed and documented and that security testing has confirmed the security of the solution and/or application? What is your practical experience to verify that this point has been correctly implemented by the organization?

soro
  • 23
  • 4
  • 1.1.1 *actually* reads "Verify the use of a secure software development lifecycle that addresses security in all stages of development." – mlp Mar 14 '21 at 23:09
  • @mlp thank you for correction – soro Mar 15 '21 at 06:14

1 Answers1

1

Section 1.1.1 refers to Proactive Controls Controls C1: Define Security Requirements

I think Section 1.1.1 can be considered as a high-level control for making sure SDLC procedure discovered and documented, and security controls, procedures, and concepts properly defined, selected, and implemented.

How to verify that this requirement is met by the company?

  • Try to understand your SDLC, what security checks are missing, what checks can be implemented for your use-case?
  • Have you implemented application security testing concepts that are a must for every SSDLC:
    • DAST
    • SAST
    • IAST
    • SCA

Is it sufficient that all five phases of the SDLC are completed and documented and that security testing has confirmed the security of the solution and/or application?

Yes and no. From a high-level perspective, yes it is enough. However, from a low-level perspective, it is not. As you have mentioned, have you actually confirmed the security of the solution and/or application? I am not talking about "It looks okay in the paper" approach but "Hands-on" one.

What is your practical experience to verify that this point has been correctly implemented by the organization?

OWASP is somewhere good to start. In my experience, it may be looking good on paper. However, it is not about the solutions that check for the security of a version. It is more about security culture and maturity of controls that implemented. I would try to make sure that every stakeholder understood why are we doing these controls and adopted them.

Tolga K.
  • 26
  • 2