CAS-003 · Question #38
A software development team has spent the last 18 months developing a new web-based front- end that will allow clients to check the status of their orders as they proceed through manufacturing. The…
The correct answer is D. Using a SRTM. The root problem is that security requirements were never defined or tracked during the 18-month development lifecycle, leading to vulnerabilities being discovered only at the end. A Security Requirements Traceability Matrix (SRTM) is the correct answer because it formally…
Question
A software development team has spent the last 18 months developing a new web-based front- end that will allow clients to check the status of their orders as they proceed through manufacturing. The marketing team schedules a launch party to present the new application to the client base in two weeks. Before the launch, the security team discovers numerous flaws that may introduce dangerous vulnerabilities, allowing direct access to a database used by manufacturing. The development team did not plan to remediate these vulnerabilities during development. Which of the following SDLC best practices should the development team have followed?
Options
- AImplementing regression testing
- BCompleting user acceptance testing
- CVerifying system design documentation
- DUsing a SRTM
How the community answered
(29 responses)- A14% (4)
- B7% (2)
- C3% (1)
- D76% (22)
Explanation
The root problem is that security requirements were never defined or tracked during the 18-month development lifecycle, leading to vulnerabilities being discovered only at the end. A Security Requirements Traceability Matrix (SRTM) is the correct answer because it formally documents security requirements from the outset and maps them to design, development, and testing phases - ensuring security is built in, not bolted on. If an SRTM had been used, security vulnerabilities related to database access would have been identified and addressed during design or early coding. Regression testing (A) verifies that new changes don't break existing functionality - it does not address missing security requirements. User acceptance testing (B) validates business functionality, not security. Verifying system design documentation (C) is too vague and does not enforce security requirements tracking throughout the SDLC.
Topics
Community Discussion
No community discussion yet for this question.