A city analytics team wants to embed an open-source charting library in an internal dashboard. What assessment is required?
Select an answer to reveal the explanation.
Short Explanation
Open source can be fantastic for city dashboards—until a nasty CVE or a license surprise shows up. Check vulnerabilities and license fit before you glue it in. Free as in puppy still needs care and feeding.
Full Explanation
Embedding an open-source charting library in an internal dashboard still requires license-obligation review and vulnerability assessment of the component. Licenses may impose distribution, attribution, or copyleft conditions that conflict with municipal policy; vulnerability assessment (and ongoing SCA) identifies CVEs in the library and its transitive dependencies. Internal does not mean unattackable—compromised insider paths, malware on admin workstations, and pivot opportunities still matter for dashboards that may visualize sensitive operational data.
Reviewing only the author's social-media follower count is popularity theater, not security or legal due diligence.
Automatic approval for any package with a README badge trusts unverified signals and skips real CVE and license analysis.
Skipping review because internal dashboards cannot be attacked underestimates insider threat, credential theft, and the value of data displayed on civic analytics views.
Exam caveat: open-source use demands both license and security assessment—CISSP often tests that pairing. Operational check: check license compatibility with counsel/policy, run SCA before merge, pin versions, prefer maintained packages, and re-check when upgrading the dashboard's dependency tree.