Before releasing an internal mobile app for code-enforcement officers, the city wants flaws found in source and assurance the binary is authentic. Which techniques fit?
Select an answer to reveal the explanation.
Short Explanation
Static analysis is the spell-check for source before officers install the app. Code signing is the wax seal that says this binary really came from the city. Unsigned mystery APKs from a file share are how you ship regret.
Full Explanation
Before officers install a municipal mobile app, two release gates reduce preventable harm. Static code analysis (SAST) examines source or bytecode for vulnerable patterns—insecure storage, weak crypto, injection sinks—while developers can still fix them cheaply. Code signing then binds the released binary to the city’s publishing identity so devices and app stores can detect tampering and refuse unsigned or foreign packages. Analysis without signing leaves distribution integrity open; signing without analysis merely seals unknown defects. Skipping analysis and distributing unsigned APKs from a public file share maximizes both code risk and supply-chain impersonation risk. Relying only on user complaints after production rollout discovers defects after officers and citizens are already exposed. Signing the app while never reviewing source accepts whatever vulnerabilities shipped in the build and treats the signature as a substitute for quality—which it is not. Exam caveat: static analysis and code signing address different layers (defect discovery vs. authenticity/integrity); exam distractors often keep one and drop the other. Operational check: require a clean or waived SAST report in the release checklist, sign with the official municipal key under controlled access, and verify devices reject unsigned builds.