A CIO asks whether the municipality’s custom-development practices are immature or advancing. Which approach best answers that question?
Select an answer to reveal the explanation.
Short Explanation
“Are we grown-ups at secure coding?” isn’t a gut feel. Use a maturity model—CMM/SAMM-style—to score practices level by level instead of counting commits or hoping nothing blew up.
Full Explanation
Answering whether municipal custom-development practices are immature or advancing requires a structured software security maturity assessment, not gut feel. Maturity models in the CMM tradition or SAMM-class frameworks define practices and levels—governance, design, implementation, verification, operations—so the organization can score consistency of threat modeling, secure coding, testing, and defect management. That assessment gives the CIO comparable language for investment, hiring, and vendor expectations around custom civic applications.
Counting lines of code shipped per month measures output volume, not security capability, and can reward risky speed. Declaring maturity from how many developers keep a personal blog confuses personal branding with organizational process strength. Avoiding models entirely and judging maturity by whether production crashed this quarter is lagging, binary, and blind to near misses and insecure-but-lucky periods.
Exam caveat: software security maturity models provide leveled practices for capability evaluation. The exam may reference CMMI-like thinking or OWASP SAMM-style approaches without requiring memorization of every level number. Maturity is about repeatable practices, not heroics or luck.
Operational check: select a SAMM- or CMM-aligned assessment, baseline the municipality’s custom-development teams and key vendors, set target levels for high-risk systems (tax, courts, benefits), and re-measure annually with evidence from pipelines, design reviews, and production incident themes.