The assessor’s office maintains valuation-model wrappers. Which secure coding practice best fits?
Select an answer to reveal the explanation.
Short Explanation
Wrappers still ship bugs and bad libraries. Code review plus dependency scanning keep assessor valuation AI from inheriting someone else’s mess.
Full Explanation
Assessor valuation-model wrappers need mandatory code review and dependency scanning as secure coding practice. Wrappers mediate data access, feature prep, model invocation, and result handling for valuations that affect tax equity perceptions; defects or malicious dependencies become production risk. Code review catches logic errors, insecure defaults, and unauthorized changes. Dependency scanning detects known vulnerable or suspicious libraries before they ship into assessment season. Together they reduce supply-chain and defect risk in the software layer around the model—not only in the model file itself.
Merging wrapper changes with no review and no dependency scanning removes two primary quality and security gates. Allowing unsigned third-party libraries of unknown origin without checks imports unaudited code into a fiscally sensitive municipal system. Disabling scanners because they “slow assessment season” trades short-term speed for preventable compromise during peak operational pressure—exactly when integrity matters most.
Exam caveat: secure coding for AI includes the wrapper/service layer; model accuracy alone does not waive review and scanning. Seasonal urgency does not justify disabling security gates.
Operational check: enforce branch protection with required reviews on valuation wrappers, run dependency and SAST scans in CI with fail-on-critical policy, inventory third-party libraries, and confirm no unscanned path can deploy to the assessor’s production scoring services.