Asset Management as the Foundation of Vulnerability Management: Unknown Assets Cannot Be Protected
Asset management is presented as the true foundation of vulnerability management because organizations cannot protect assets they do not know exist. The article stresses that without accurate, up-to-date inventory data, vulnerability management produces only meaningless reports.
Data can be collected from multiple sources beyond vulnerability scanners: SIEM systems, NTA/NDR traffic analysis, Active Directory and CMDB, virtualization and orchestration platforms, cloud APIs, and manual input when automation is incomplete. Each source covers only part of the environment, so the central task is merging these fragments into one reliable picture while validating ownership and data accuracy.
A minimal asset record must include network address, MAC address, hostname, owner, department, and approval status. For vulnerability management three additional fields are essential: asset criticality that drives SLA requirements, a named responsible person or team for remediation, and the date of the last successful data collection. Without the last field, teams cannot distinguish between assets that have no vulnerabilities and assets the scanner has been unable to reach for months.
Why Categorization Matters
Assets are grouped by importance to focus limited resources on those involved in attack paths leading to unacceptable events. High-importance assets typically include perimeter web servers, network devices, VPN gateways, and critical business systems such as 1C:Accounting. Medium-importance assets provide indirect access, while low-importance assets do not lead to prohibited outcomes when compromised. Executive and chief accountant workstations are automatically treated as high importance because they often provide direct paths to key systems.
The guiding principle is to treat unknown assets as critical until proven otherwise. NIST CSF 2.0 and CIS Controls both recommend this conservative approach because the cost of an extra scan is far lower than the cost of a missed incident.
Regulatory Requirements
Russian regulations now explicitly require asset inventory. FSTEC Order No. 117 effective 1 March 2026 names inventory systems as a data source for configuration control. Monthly vulnerability detection and 24-hour remediation of critical issues become impossible when half the infrastructure remains unknown. Federal Law No. 58-FZ and Government Decree No. 1762 introduced industry-specific lists of critical information infrastructure objects, shifting categorization from self-defined analysis to comparison against official sector lists.
International standards impose similar obligations. CIS Controls v8.1 Control 1 requires accurate inventory of all corporate assets with semi-annual reviews and weekly reaction to unauthorized devices. NIST CSF 2.0 ID.AM-08 adds explicit lifecycle management, recognizing that decommissioning breaks asset data as severely as onboarding. ISO/IEC 27001:2022 A.5.9 and A.5.12 mandate inventories of information assets and their classification.
New Asset Types and Attack Surface Expansion
The asset landscape has changed dramatically. Forgotten cloud resources continue to incur costs and host real vulnerabilities for an average of 31 days before discovery. SaaS applications adopted by marketing, development, and HR teams often bypass IT registration yet contain corporate data. EU AI Act and ISO/IEC 42001 now require registers of AI systems, while NIST AI RMF pushes similar mapping requirements. Containers, Kubernetes clusters, IoT devices, and industrial control systems further expand the attack surface.
The article concludes that vulnerability management quality depends directly on the completeness, accuracy, and currency of asset data. Continuous reconciliation between CMDB, monitoring systems, and orchestration tools is necessary because no single source remains authoritative over time.
Related articles
Merkle Tree Certificates Proposed to Enable Lightweight Post-Quantum HTTPS in Chrome
Google Chrome developers, together with industry partners and the IETF PLANTS working group, are introducing Merkle Tree Certificates (MTC) as the first HTTPS change designed to address performance challenges of post-quantum cryptography. The new format replaces parts of traditional X.509 certificate chains with compact inclusion proofs inside a Merkle tree whose root is signed by a certificate authority. This approach significantly reduces the size of authentication data exchanged during TLS handshakes while preserving strong post-quantum security properties. MTC also enforces Certificate Transparency by design, making it impossible to issue a public certificate without recording it in a publicly verifiable log. Performance evaluations are currently underway with Cloudflare, and initial public MTC logs operated by experienced CT log providers are planned for early 2027. A dedicated post-quantum Chrome Root Store supporting only MTC is scheduled for the third quarter of 2027 and will run in parallel with the existing root store.
AI Resume Screening Barriers Push Young IT Talent Toward Cybercrime
Young Russian IT graduates with relevant projects and freelance experience are struggling to secure entry-level roles in information security and antifraud due to automated resume filters demanding prior commercial experience. Data from SuperJob and Habr Careers shows only 10-11% of IT vacancies in early 2026 were open to candidates without experience, compared to 37-38% across the broader labor market, with most junior openings limited to technical support. Russian court statistics reveal that 67.9% of those convicted for computer-related crimes under Article 272 were under 30, aligning with the age when graduates first seek professional experience. International studies, including research from Harvard Business School and Accenture, highlight how overly rigid automated screening discards capable candidates lacking formal tenure. Programs like the UK's National Crime Agency Cyber Choices demonstrate that providing legal pathways in cybersecurity can reduce recidivism. The article argues that excessive reliance on AI filters without human review of projects or practical tests exacerbates the pipeline problem in a sector claiming talent shortages.
Bill Gates Calls for Stronger External Oversight and Regulation of AI
Bill Gates stated in an NBC News interview that self-regulation by AI developers is no longer sufficient and urged Congress to pass binding laws on artificial intelligence. He warned that AI tools in the hands of malicious actors could trigger catastrophic events capable of causing up to a billion deaths, emphasizing the unprecedented power of combining bad intentions with modern AI systems. Gates advocated for mandatory rules, audits, and monitoring, particularly in critical sectors such as medicine, finance, and government infrastructure, while acknowledging that some added bureaucracy would be necessary. Leaders from Anthropic and OpenAI have similarly suggested slowing AI development, with former Anthropic employee Jacob Coxon publicly accusing companies of playing roulette with lives by pursuing self-improving superintelligence. House Speaker Mike Johnson prefers to wait for industry proposals, whereas Mark Zuckerberg opposes coordinated oversight and believes individual labs should decide on pace. Several U.S. states including California, Maryland, and New York have already begun launching their own AI regulatory initiatives and expert panels.
Implementing DevSecOps in Unprepared Teams: A Practical Three-Month Roadmap
Many development teams face resistance when security tools are introduced without proper process changes, leading to bypassed checks and unresolved findings. The article outlines a structured approach for small teams of five to eight developers without a dedicated security specialist, focusing on one service as a pilot. It emphasizes assigning clear roles including a Security Champion, selecting initial checks such as secret scanning with Gitleaks and dependency analysis, and converting scanner reports into actionable tasks with owners and deadlines. The plan covers the first eight weeks of setup, including baseline handling for legacy issues, automated blocking rules, and incident rehearsal exercises. Metrics recommended include time to first triage, age of open critical defects, and false positive rates, aligned with DORA indicators for release performance. The guidance draws on OWASP SAMM practices and stresses that security requirements must be integrated into daily workflows rather than added as extra gates.