Custom fee-calculator code for city building permits is about to release. What should security assessment include before production?

Code review and security-focused testing before production are core Domain 6 control-assessment activities for custom applications. A municipal building-permit fee calculator processes financial logic and user input; flaws can enable fee manipulation, injection, broken access control, or disclosure of permittee data. Performing structured code review plus security testing (SAST/DAST, logic-abuse cases, authorization checks) before release finds those issues when remediation is cheapest and before citizens and contractors depend on the calculator in production.

Skipping review because ‘fee math has no security impact’ misunderstands application risk: financial logic is a prime target for abuse and often intertwines with authentication, session handling, and input validation. Shipping immediately and opening a bug bounty only after public launch inverts the secure SDLC—external researchers become the first line of defense after exposure. Limiting testing to UI color and font checks addresses aesthetics, not security properties, and leaves injection, authz, and business-logic flaws unexamined.

Exam caveat: Assessment of software includes code review and testing as primary techniques. Do not confuse cosmetic QA with security assessment, and do not treat post-release bounty programs as a substitute for pre-release review when the question asks what should happen before production.

Operational check: Require security code review sign-off and a defined set of security test cases for fee calculation, discounts, and role-based access before the change advisory board promotes the build; retain findings and remediation evidence with the city’s SDLC artifacts for the permit system.