# Ceron — full service reference > AI-assisted security audits for web applications, APIs, cloud infrastructure, and access controls. Canonical website: https://getceron.com/ Pricing and FAQs: https://getceron.com/pricing ## About Ceron About: https://getceron.com/about Ceron was founded by Mario Luckeneder and is based in Scottsdale, Arizona. Ceron uses AI-assisted investigation, verified findings, and prioritized remediation guidance to help organizations understand their security exposure. ## Coverage Ceron assesses only the assets and access authorized for the engagement: - Internet-facing assets: approved websites, APIs, and exposed services; no internal access required. - Cloud and infrastructure: configuration and permissions in authorized cloud accounts. - Identity and access: authentication and role boundaries using provided test accounts. ## Approach and deliverables 1. Set boundaries: agree on assets, access, testing methods, timing, and a fixed fee before work starts. 2. Test and verify: AI assists investigation of configuration, exposed services, and access controls within scope. Potential issues are checked against evidence before reporting. 3. Deliver next steps: leadership receives a risk summary; engineering receives affected assets, evidence, severity, business impact, and prioritized remediation guidance. Coverage and limitations are documented. Every audit includes an agreed asset inventory and testing boundaries, AI-assisted assessment and finding validation, severity ratings and business impact, evidence and prioritized remediation guidance, an executive summary, and a technical report. ## Core audit From USD 1,500, one time, for a defined, straightforward environment. Core coverage can include up to 3 web applications or APIs, 50 internet-facing assets, and 3 cloud accounts. Exact coverage is confirmed before testing. ## Extended audit Custom fixed quote with no subscription. For larger asset inventories, complex access roles, internal networks, or deeper testing across systems. Includes Core audit deliverables, multiple environments and asset groups, additional access roles and trust boundaries, and penetration testing within agreed boundaries. Fee and delivery window are agreed upfront. ## No findings, no fee A qualifying finding is a verified, actionable vulnerability within the agreed scope. Informational observations alone do not trigger payment. The fixed fee does not increase with the number of findings. If no qualifying vulnerability is found, the audit fee is USD 0 and the customer still receives a scope and assessment outcome summary. Pricing depends on assets, environments, and testing depth. USD 1,500 is a starting price, not the price for every company. Remediation implementation and follow-up testing are separate unless included in the agreed scope. The report illustrated on the homepage uses synthetic findings. It is not a customer case study or evidence of actual customer vulnerabilities. ## Frequently asked questions ### What access do we need to provide? You choose the assets and access included in the audit. An external assessment can begin with approved public-facing assets. Cloud, internal, or authenticated testing requires separately agreed permissions. The report identifies any limits caused by unavailable access. ### How is our data handled during the audit? Before granting access, agree in writing on the data the assessment may use, any AI providers involved, retention and deletion terms, and how findings will be delivered. These terms belong in the engagement scope before testing begins. ### Do I pay anything if you find nothing? No. If the agreed assessment finds no verified, actionable vulnerability, the audit fee is $0. You still receive a summary of the scope and assessment outcome. ### Is $1,500 the price for every company? It is the starting price for a focused audit. Larger asset counts, additional environments, and more complex testing receive a custom fixed quote before work begins. ### How is severity determined? Findings are rated Critical, High, Medium, or Low based on evidence, exploitability, potential impact, and the context of your environment. The report explains the reasoning and what to prioritize. ### Does a clean audit mean we are completely secure? An audit is a point-in-time assessment within agreed boundaries. No findings means none were identified in that assessment; it does not guarantee that every vulnerability has been discovered. ### Does the audit include fixing the issues? The audit includes remediation guidance. Implementation and any follow-up testing are separate work unless explicitly included in your agreed scope. ### Will testing disrupt our business? Testing boundaries, permissions, and timing are agreed before work begins. Disruptive testing requires explicit authorization. Your engagement defines the permitted methods and stop conditions. ## Blog Ceron Blog: https://getceron.com/blog Author profile and article archive: https://getceron.com/authors/mario-luckeneder Practical perspectives on application security, AI threats, cloud risk, and security audits. ### SaaS Invitation Security: Test Who Can Join Your Customer Workspaces URL: https://getceron.com/blog/saas-invitation-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-10-08T00:00:00-07:00 SaaS Invitation Security: Test Who Can Join Your Customer Workspaces An administrator invites a contractor into a customer workspace with read-only access. Before the contractor accepts, the administrator cancels the invitation. The security question is simple: does the old link still let someone in? A SaaS invitation security assessment examines the full path from creating an invitation to granting membership. It verifies the intended recipient, the destination workspace, the permitted role, and the invitation’s current validity. These checks matter because an invitation can grant access to information the recipient could not reach a moment earlier. The invitation email is only one part of that path. Your assessment should follow the resulting membership through the application and its APIs, using controlled workspaces and synthetic records. Define what accepting an invitation is allowed to do Start with a written rule for each invitation type. An email-bound invitation might require the accepting account to verify the exact intended address. A deliberately shareable link might admit anyone holding it, within a restricted role and lifetime. Both designs need an explicit access policy; an assessment cannot judge recipient binding without knowing which behavior the business intends. Build a small permission matrix with an owner, an administrator, a member, and a guest. For each role, identify who may invite others and which roles they may grant. Include invitations sent through the API and bulk onboarding tools, rather than reviewing only the visible button. Bind the recipient, workspace, and role at the server During an authorized assessment, use two test workspaces and two unrelated test accounts. Send an email-bound invitation to the first account, then try accepting it while signed into the second. Verify the stored membership and actual access, even if the page displays a reassuring error. Next, check whether the acceptance request can change the workspace or requested role. The server should apply the approved invitation’s attributes and current policy. A hidden field, disabled dropdown, or workspace identifier in the browser is not evidence that those boundaries are enforced. [OWASP’s multi-tenant security guidance](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) emphasizes validated tenant context and tenant isolation. For invitations, apply that principle to the membership being created: establish which workspace the server actually authorized and which records that membership can access. Test cancellation, expiration, and repeat acceptance Treat invitations as a lifecycle. Record the expected result for pending, accepted, canceled, and expired invitations. A canceled link should not create a new membership. An expired invitation should follow the documented renewal process rather than silently extending its own validity. Use a designated invitation to test repeat acceptance. The operation should not create duplicate memberships, restore a removed user, or reapply an old privileged role. If a user has been downgraded after joining, reopening the original invitation must not become an unexpected promotion path. For sensitive invitations, review what happens when the inviter loses authority before acceptance. Decide whether pending grants remain valid or require a fresh administrator decision. Test the chosen rule and record exceptions, such as a separately governed onboarding process. Check the first actions the new member can perform An acceptance screen can be correct while the resulting permissions are too broad. After each test, attempt the functions that define the role: reading a designated project, downloading a file, changing settings, inviting another user, and accessing billing. Use synthetic data and avoid actions outside the agreed scope. Keep an audit record that connects invitation creation, acceptance, role changes, and removal. A useful finding shows the actor, destination workspace, approved role, observed permission, and time of the test. Sanitize invitation tokens before sharing evidence. Turn the finding into a verifiable fix A concrete remediation might bind acceptance to the verified recipient, resolve role and workspace from the server’s invitation record, or reject canceled invitations before writing membership. Choose the fix for the demonstrated failure rather than adding a generic confirmation screen. Retest the original failure and normal onboarding. Confirm that the approved recipient can still join with the intended access, while the wrong account, canceled link, and unauthorized role change fail. Retain the final membership state as evidence; an HTTP status alone may not establish the outcome. For a Ceron engagement, agree the invitation channels, test roles, identity providers, and customer boundaries in scope. Authenticated testing needs suitable test accounts. A public website check cannot establish how private workspace invitations behave. SaaS invitation security FAQs Is a long invitation token enough? An unpredictable token helps resist guessing. It does not establish the intended recipient, correct role, current validity, or workspace isolation. Those decisions need their own checks. Should every invitation be tied to an email address? Match the mechanism to the product’s access policy. Email-bound invitations should enforce that binding. Shareable invitations need deliberate limits on role, lifetime, and who may create them. What evidence should the assessment deliver? Ask for the agreed access rule, sanitized acceptance requests, the membership created, and proof of the resulting permissions. Include a retest showing both rejected abuse and successful legitimate onboarding. Plan your customer workspace assessment If invitations are how customers add employees, contractors, or partners, include them in your next [customer portal security assessment](https://getceron.com/blog/customer-portal-security-assessments-protecting-the-systems-your-clients-log-into). Ceron’s [retesting guide](https://getceron.com/blog/security-assessment-retesting-how-to-verify-vulnerabilities-have-actually-been-fixed) explains how to verify the resulting fix. [Discuss your assessment scope with Ceron](https://getceron.com/book). The workspace and contractor examples above are illustrative test scenarios. ### CSRF Security Assessment: Can Another Website Trigger a Business Action? URL: https://getceron.com/blog/csrf-security-assessment-business-actions Author: Mario Luckeneder, Founder of Ceron Published: 2026-10-07T00:00:00-07:00 CSRF Security Assessment: Can Another Website Trigger a Business Action? Your finance administrator signs into the customer portal, then opens another website in a second tab. Could that website cause the portal to change a payout address using the administrator’s existing session? A CSRF security assessment tests whether a browser can be induced to submit an unwanted action to an application where the user is already authenticated. Cross-site request forgery becomes a business risk when the application treats the presence of a session as sufficient evidence that the user intended the change. The right starting point is an inventory of meaningful actions: changing account details, adding users, rotating credentials, approving transactions, or deleting records. The assessment then establishes which requests a browser can actually send and whether the server rejects unwanted changes. Start with the action and its authentication mechanism Map each sensitive action to its endpoint, accepted method, request format, and authentication mechanism. Cookie-authenticated browser requests deserve particular attention because the browser can attach eligible cookies automatically. An API using a bearer token explicitly supplied by trusted application code has a different exposure model, which still needs to be verified. Use a harmless stand-in for the real business operation. For a payout workflow, change a synthetic account’s notification preference or a designated test payment record. The test should demonstrate the same protection boundary without moving money or changing production customer details. Include older forms, administrative pages, alternate API routes, and mobile web interfaces. A new frontend may protect its requests while an older route still accepts the same change without the expected validation. Document each reachable path to the business action. Verify that the server requires evidence of an intended request [OWASP’s CSRF prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) describes established defenses including framework protections, validated tokens, origin checks, and request metadata. Use the application’s architecture to choose and test the relevant controls. If the application relies on a CSRF token, verify the server rejects an absent or invalid token. With separate controlled sessions, test whether a token from one session is accepted for another when the design requires session binding. A token visible in a form proves little until the backend validates it. If origin validation is the control, inspect the exact permitted origins and the handling of missing or unexpected headers. Broad exceptions added for a legacy integration should have a documented purpose. Check that reverse proxies do not cause the application to evaluate the wrong destination origin. A sensitive state change should not occur through an ordinary read-only navigation. Review routes using GET for operations such as removing a member or approving a request. Correcting the method is part of the fix, but the replacement route still needs suitable request validation. Separate cookie settings from the complete protection decision SameSite cookie settings influence when a browser sends cookies. Verify the actual session cookie attributes and browser behavior in the relevant workflow. Authentication redirects and embedded applications may create legitimate requirements that the assessment must account for. Do not assume a sibling subdomain is outside the same-site boundary. An organization can have a trusted account portal and a less trusted marketing or user-content service under related hostnames. Review that relationship when evaluating the protection afforded by cookie settings. OWASP treats SameSite as a defense-in-depth measure in many application designs. Your report should explain which observed condition blocks the unwanted request, rather than equating one cookie attribute with complete coverage. CORS also needs precise interpretation. Restricting whether another origin can read a response does not by itself establish that the application rejected a state-changing request. If the application relies on a required custom header and browser preflight behavior, verify that requirement on the server and check for alternate request formats that avoid it. Reproduce the browser path and inspect the saved result A command-line request with manually attached cookies does not prove that a separate website could cause the same request in a user’s browser. Reproduce the proposed scenario with a controlled origin, a designated test user, and the browsers relevant to the application. Record whether the session was attached, which protection checks ran, and whether the application changed state. Inspect the resulting account or transaction record after the attempt. A blocked response and an unchanged record establish more than a screenshot of a test page. Keep the demonstrated impact specific. A reversible profile preference is different from a new administrator or a financial change. Assess the privileges the affected user would need and the actual conditions required for the browser path to work. Do not inflate a theoretical request into a confirmed exploit. Investigate exceptions that bypass the main protection Many applications apply request protection centrally, then exempt endpoints for integrations. Review that exception list against the actual authentication behavior. A webhook that validates a service signature has different requirements from a browser endpoint accepting the user’s session cookie. Sharing a URL prefix does not make those mechanisms interchangeable. For each exception, ask who owns it, why it exists, and what prevents an unwanted action. Check whether the endpoint accepts more than one authentication method. An API intended for token-authenticated clients may also accept the browser session as a convenience; that fallback can change its CSRF exposure. Test content-type handling with the development team. If the endpoint is intended to accept only JSON plus a required application header, establish whether other accepted formats reach the same operation without that header. Keep the test focused on the observed parser and browser behavior rather than an abstract list of possible payloads. Review login and account-linking flows separately. Their outcome may change which account the browser uses or which external identity becomes connected. Define the expected user decision and verify the flow’s request binding. Do not assume that a route has no security consequence merely because it appears before the main authenticated dashboard. For each confirmed gap, record the narrowest affected route and the shared component responsible. A fix in middleware should cover the relevant route family, while an endpoint-specific fix needs a documented reason. That distinction helps the team choose regression cases that catch the same mistake elsewhere. Retest the fix alongside ordinary customer workflows After remediation, repeat the original browser scenario, invalid-token cases, and alternate routes. Confirm the unwanted change fails before it takes effect. Then exercise the normal frontend and approved integrations to ensure legitimate requests still complete. For high-impact operations, consider whether the product also needs fresh authentication or a user confirmation tied to the specific transaction. Such controls should serve a defined business purpose and accompany the underlying request protection. Agree these cases in a Ceron application assessment’s scope, including permitted actions, accounts, browsers, and stop conditions. Testing authenticated business actions requires more access than an external website check. The deliverable should identify the demonstrated path, the business impact, the fix, and its verified retest. CSRF assessment FAQs Does HTTPS prevent CSRF? HTTPS protects traffic in transit. It does not establish that the signed-in user intended a particular state change. Request protection must address that separate question. Does every API need the same CSRF control? No. Evaluate how credentials reach the endpoint and what another origin can cause the browser to send. Cookie authentication and explicitly supplied authorization headers have different properties. What counts as proof that the issue is fixed? Repeat the demonstrated browser path and verify that no unauthorized state change occurs. Check the server decision and confirm the intended application workflow still succeeds. Include sensitive business actions in your next assessment Use Ceron’s [website security audit guide](https://getceron.com/blog/website-security-audit-for-businesses) to define authenticated coverage. The [WAF assessment guide](https://getceron.com/blog/waf-security-assessment-proof-beyond-blocked-requests) explains why blocked traffic alone is insufficient evidence of application safety. [Discuss your application assessment with Ceron](https://getceron.com/book). The finance scenario is illustrative; it is not a reported customer incident. ### CSV Formula Injection: Assess What Happens When Staff Open an Export URL: https://getceron.com/blog/csv-formula-injection-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-10-06T00:00:00-07:00 CSV Formula Injection: Assess What Happens When Staff Open an Export A support supervisor downloads a CSV of customer tickets and opens it in a spreadsheet. A customer-supplied subject is evaluated as a formula instead of displayed as text. The application has moved untrusted input into a tool that can interpret it as an instruction. CSV formula injection testing examines that handoff. It establishes which exported fields outsiders control, which spreadsheet readers staff use, and whether those readers evaluate the values. The severity depends on the demonstrated behavior and environment; a suspicious string alone does not prove a compromised computer. Find the fields outsiders can influence Review downloads used by finance, sales, support, and operations. Include emailed reports and scheduled exports. For each column, trace the source: customer names, ticket subjects, shipping notes, vendor imports, and form responses may all contain untrusted values. An administrator-only export can still carry customer-controlled content. Record both the person who supplies the value and the person who opens the file. Those are different trust decisions. Check formatting and formula evaluation separately CSV quoting preserves rows and columns, but it does not necessarily force a spreadsheet to interpret a cell as text. Verify both the generated file structure and the reader’s treatment of its contents. [OWASP’s CSV injection guidance](https://community.owasp.org/attacks/CSV_Injection) explains the risk of formula-leading input and cautions that handling varies across spreadsheet applications. Test the business’s supported readers and import methods rather than relying on a generic escaping claim. Include values containing delimiters, quotation marks, and line breaks. An input that creates an unexpected cell can change which characters appear at that cell’s beginning. A safe-looking web preview does not establish the behavior after download. Demonstrate the issue with a harmless marker In an agreed test environment, use a benign formula that produces a fixed visible result. It should not make network requests, read files, or launch programs. Enter it in a designated field, export the record, and open the file through the normal staff workflow. Record whether the reader displays literal text or an evaluated result. Retain the exported bytes, spreadsheet version, import settings, and sanitized screenshot. Direct opening and an import dialog may behave differently, so cover the routes staff actually use. Report only the impact established. Formula evaluation does not automatically mean remote code execution or data theft; those outcomes require separate authorized evidence. Fix the export without damaging legitimate data Choose a handling policy for the destination. A human-facing XLSX export can explicitly write untrusted values as text cells, provided the generating library preserves that type. For CSV, verify the chosen neutralization strategy in every supported reader. Avoid deleting all leading punctuation: legitimate names and identifiers can contain it. If protective prefixes would break a machine integration, define separate export paths with appropriate handling for each consumer. Retest ordinary values, the original marker, column boundaries, row counts, and multiline text. Include saving and reopening when that is part of the staff workflow. The acceptance condition is inert text and preserved business data throughout the verified path. CSV formula injection FAQs Is quoting enough? Not necessarily. CSV structure and spreadsheet interpretation are separate properties to test. Are internal reports affected? They can be when they include values supplied by customers, suppliers, or other users. What should Ceron assess? Agree the input fields, export endpoints, staff roles, spreadsheet readers, and representative files. Public website scanning cannot establish the downstream reader’s behavior. Review your export workflow Pair this review with Ceron’s [export authorization guide](https://getceron.com/blog/background-export-jobs-authorization) and [file processing security guide](https://getceron.com/blog/file-upload-processing-security). [Discuss an export assessment with Ceron](https://getceron.com/book). The support example is an illustrative assessment scenario. ### AI Agent Sandbox Security: What Your Assessment Should Verify URL: https://getceron.com/blog/ai-agent-sandbox-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-10-05T00:00:00-07:00 AI Agent Sandbox Security: What Your Assessment Should Verify A developer gives an AI agent a disposable workspace, watches it build an application, and deletes the workspace when the task finishes. That sounds contained. The security question starts with everything the workspace could reach before it disappeared: source repositories, deployment credentials, customer files, package registries, and the preview link shared with a colleague. A sandbox can isolate files and processes while still giving an agent access to company accounts. Before adopting it, check what the agent can send out, which credentials it receives, and what remains after the workspace is deleted. Start with the business authority inside the workspace Write down the task in ordinary language. An agent fixing a layout needs a copy of the relevant code and a way to show its changes. It may not need production database access, billing permissions, or a credential that can publish directly. Compare that task with the environment the agent actually receives, including inherited variables, mounted directories, and helper processes. Suppose an agency runs tasks for three clients in separate containers. If all three containers receive a deployment credential that works across every client, one task can still affect another client’s site. Test what the credential allows, even when the containers themselves are isolated. Outbound connections decide where information can go An isolated filesystem can still coexist with broad network access. Ask which destinations a task needs and who enforces that list. Package installation, repository access, and a preview service may each be legitimate, but they should have identifiable purposes and owners. For a controlled assessment, place a synthetic marker in a test file and use a destination owned by the test team. Attempt a transfer outside the approved destination set. Retain the attempted destination, the enforcement decision, and confirmation that the marker did not arrive. A model saying it will respect the rule is less informative than a network or service control rejecting the request. Also inspect permitted destinations. An approved storage service may contain both a company account and an unrelated account. Allowing the service’s hostname does not establish that every account on it is an appropriate recipient. Where that distinction matters, application authorization must accompany network restrictions. A snapshot creates another copy to govern [Cloudflare’s September 30 sandbox update](https://blog.cloudflare.com/faster-agent-sandboxes/) includes runtime image selection and filesystem snapshots in public beta. Snapshots make it easier to resume a task, but they also leave another copy of its files. Check what gets deleted when a task ends and what stays in storage. Trace an illustrative task through creation, pause, restoration, and retirement. Put a non-secret identifier in its workspace, save a snapshot, then remove the original user’s access. Test who can restore the snapshot and which identity the restored task uses. Record whether credentials are refreshed under current authorization or retained from an earlier session. Choose retention based on the information in the workspace. A snapshot holding only public code has a different handling requirement from one containing confidential customer exports. The useful inventory lists snapshot owner, source task, storage location, permitted restorers, and deletion policy. A list of running containers will miss this entire lifecycle. Treat preview links as application access An agent’s preview can expose unfinished account controls, debug responses, or test records. Review how the preview is authenticated, how it is associated with its task, and when it expires. Check whether access to the platform automatically grants access to every preview, including another client’s work. Use two synthetic client workspaces and two users. Confirm the intended reviewer can open the correct preview, then attempt the same link as the other user and without a session. After retiring the task, test the old link again. The evidence should show authorization decisions and the actual response, with no real customer information involved. Define what Ceron should verify before adoption For a Ceron assessment, scope the agent platform, workspace controller, connected credentials, and public preview surface explicitly. Agree which components can be tested and which require evidence from the hosting provider. An external website scan alone cannot establish container isolation or inspect private credential handling. Record the test results for client separation, outbound transfers, permissions after restoration, and expired previews. Document exceptions with the reason they exist. A build that needs broad registry access still needs controls to keep its secrets from leaving with a package request. Before approving the platform, ask for evidence that each task receives only the access it needs and loses that access when the work ends. Include restored workspaces and saved snapshots in that check. Related assessment guidance [Ceron’s guide to AI agent permissions](https://getceron.com/blog/ai-agent-permissions-business-workflows) covers business actions behind connected tools. [The AI application launch checklist](https://getceron.com/blog/vibe-coding-security-what-to-audit-before-deploying-an-ai-built-application) addresses the application the agent produces. The agency and workspace scenarios above are proposed assessment cases, not reported customer incidents. ### WAF Security Assessment: What Blocked Requests Actually Prove URL: https://getceron.com/blog/waf-security-assessment-proof-beyond-blocked-requests Author: Mario Luckeneder, Founder of Ceron Published: 2026-10-04T00:00:00-07:00 WAF Security Assessment: What Blocked Requests Actually Prove A web application firewall dashboard can look reassuring: thousands of blocked requests, familiar attack names, and a line moving in the right direction. None of those numbers answers the question a business is actually paying to resolve. Can an unauthorized person reach customer data, change a transaction, or interrupt an important service? Start by mapping what the WAF protects and which routes bypass it. Then test the application behind it. A blocked-request count can help describe traffic, but it cannot show whether customer data is protected. Separate a request reaching the application from an exploit succeeding A request can pass the firewall and still be harmless because the application rejects it, treats it as ordinary data, or has no vulnerable component. Conversely, a successful account-to-account data request may look completely normal to an attack-pattern detector. The outcome has to be established at the application. [Cloudflare’s September 29 account of adaptive WAF testing](https://blog.cloudflare.com/adaptive-ai-waf-testing/) describes treating unblocked requests as leads to investigate. The company used human review to establish what those requests actually did. Ask for the same validation in your assessment report. Ask the assessor to classify observations precisely. Was the request rejected at the edge? Did it reach the origin? Did the application perform an unauthorized action? What evidence establishes that action? These answers prevent a dramatic screenshot of an HTTP response from being mistaken for a demonstrated business impact. Confirm the protected route is the route customers actually use Inventory the production hostname, API hostname, regional endpoints, file service, and any direct origin address. For each, identify whether the intended controls apply. A firewall protecting the marketing domain says little about a customer API hosted elsewhere. For example, a SaaS company may put its browser application behind a WAF while mobile clients use a separate API. Both paths reach the same database. If the assessment covers only the website, it can miss the API’s account-permission checks. Include both paths in the agreed asset list. Where authorized, test whether the origin accepts equivalent requests outside the intended edge route. Use harmless requests and retain the response and origin configuration evidence. If direct access is required for an operational reason, document the authentication or network restriction that governs it. The goal is to establish the effective boundary, not to assume every alternate endpoint is automatically a vulnerability. Include requests that are valid but unauthorized Business logic deserves its own assessment cases. Two test customer accounts can establish whether account A can read account B’s invoice, modify its delivery details, or download its export. Use synthetic records and the application’s normal request formats. These tests answer questions about ownership and permissions. They do not require a visibly unusual payload. A WAF result cannot replace them because a well-formed request can still ask for the wrong person’s information. Also review privileged operations. Can an ordinary user choose an administrative role in a request? Does a support action require current authorization? Does a queued export recheck the user when the file becomes available? Select cases from the actual product, rather than making the number of firewall alerts the measure of coverage. Retest a mitigation without losing legitimate customers A new blocking rule should have two acceptance conditions. It must stop the demonstrated unwanted behavior, and it must preserve the business operation customers are supposed to complete. A rule that blocks every checkout request can eliminate an attack and eliminate the store’s revenue at the same time. Build a small regression set around the affected function. Include ordinary inputs, legitimate edge cases, and the reproduced security case. Record results at both the edge and application. If the issue is temporarily mitigated by a rule, keep the underlying application fix assigned to an owner with a date for verification. What to ask for in a Ceron engagement Scope a Ceron assessment around the application and the controls protecting its real public interfaces. Specify test accounts, permitted actions, rate limits, and whether direct-origin validation is authorized. For authenticated business logic, provide the roles needed to test the relevant boundaries. The report should distinguish a confirmed vulnerability, a control gap, and an observation requiring additional evidence. It should also say when a result depends on the tested WAF configuration. After a rule or application change, retest the original path and the legitimate transaction, then document which risk was reduced. A product owner should be able to follow a finding from the reachable endpoint to the unauthorized action, then see the retest showing that the fix stopped it. Ask for that evidence when deciding whether to close the issue. Further reading [Ceron’s website audit guide](https://getceron.com/blog/website-security-audit-for-businesses) explains scope and deliverables. [The retesting guide](https://getceron.com/blog/security-assessment-retesting-how-to-verify-vulnerabilities-have-actually-been-fixed) covers verifying remediation. The SaaS example and regression design above are illustrative assessment recommendations. ### Remote Access Security Assessment: Who Controls Your Computers? URL: https://getceron.com/blog/remote-management-software-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-10-01T00:00:00-07:00 Remote Access Security Assessment: Who Controls Your Computers? Remote support software lets your IT provider fix a computer. It may also let the operator install software, retrieve files, or reconnect after the employee closes the support window. Check who has that access, how they obtained it, and when it ends. That decision cannot be made from the software’s brand or digital signature alone. A legitimate application connected to an unauthorized operator is still unauthorized access. An assessment needs to establish the relationship behind the tool. A recognized application can be the wrong installation [Microsoft’s September 29 research](https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access/) describes phishing that delivered legitimate remote management installers under misleading names. In the observed activity, one remote administration tool installed a second channel. Microsoft distinguished this misuse from exploitation of a vulnerability in ScreenConnect itself. Check which management account controls the installed agent, who approved enrollment, and whether it belongs to your current IT provider. Recognizing the software vendor is only the first check. Take a 40-person company whose IT provider installs an approved support product. An employee later downloads the same product from an unsolicited support link. Both copies may carry the vendor’s signature, but the second can belong to someone else’s management account. An allowlist based only on the vendor can miss this. Build an inventory that includes the operator For each remote access installation, record the device, software, management tenant or server, business owner, approving ticket, and access mode. Distinguish an attended support session from unattended access that survives a restart. Include deployment tools and scripts that can install additional agents. Reconcile that record with actual endpoint observations. Ask the provider for its enrolled-device list, then compare it with installed services and the organization’s device inventory. Investigate devices present on only one side. An old laptop still enrolled after a provider change is an operational gap worth resolving, even if no malicious activity is found. The assessment should state its limits. A public-domain check cannot inspect services on employee computers or identify the tenant controlling them. Endpoint access or appropriate evidence from the administrator is needed for that portion of the review. Define how a support request proves its identity The employee should have a known route to the help desk that does not depend on the incoming message. A request to install remote support software should resolve to an approved ticket or a callback using an established contact. An urgent voice call and a familiar logo are insufficient evidence of that relationship. Test the process as a tabletop exercise. Give a participant a synthetic request claiming that a meeting application needs repair. Ask what they would verify, who can approve installation, and how they report uncertainty. Measure whether the person can reach the real help desk quickly. A process that exists only in a policy document will be hard to use during a busy workday. Keep the normal support experience workable. If legitimate assistance routinely requires employees to bypass the written process, the organization is teaching people that bypasses are normal. Resolve that mismatch before treating training attendance as evidence the workflow is safe. Test retirement and redundant access paths Use a designated test device to verify the end of a support relationship. Remove the authorized operator’s grant or uninstall the agent according to the agreed procedure. Then check whether remote access still works after a restart and whether a second authorized test channel remains. Retain the initial inventory, removal action, final service state, and access-test result. If the endpoint shows evidence of an unapproved installation, preserve relevant logs and involve the incident response owner before routine cleanup removes useful evidence. The depth of that investigation depends on what the tool could do and what activity is observed. Make this part of Ceron’s agreed assessment scope When remote support is relevant to a Ceron engagement, identify the public management interfaces, account controls, endpoint evidence, and provider responsibilities in advance. Testing the application portal and reviewing the enrolled fleet are different pieces of work. Make both boundaries explicit rather than assume one implies the other. Ask for an inventory of operators and devices, unresolved enrollment discrepancies, and the results of access-removal tests. Each finding should explain what the operator could do. For example, an unapproved account might still control a computer used to administer customer systems. Ask your provider to show which devices it can control and which staff can connect to them. When you remove that access, repeat a connection test and keep the result with the removal record. Related Ceron guidance [The IT provider handover guide](https://getceron.com/blog/switching-it-providers-why-your-company-should-consider-a-security-assessment-during-the-handover) addresses retiring old access. [The vendor access guide](https://getceron.com/blog/vendor-access-phishing-resistant-mfa) covers authentication for external administrators. The company and support exercise above are illustrative. ### Microsoft 365 Device Code Phishing: What Businesses Should Test URL: https://getceron.com/blog/device-code-phishing-business-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-28T00:00:00-07:00 Microsoft 365 Device Code Phishing: What Businesses Should Test An employee receives a document invitation, follows the sign-in instructions, and lands on a genuine Microsoft page. The address looks right. The employee completes authentication successfully. The missing question is whose application receives the access that authentication approves. Device code phishing exploits that gap. For a company assessing its Microsoft 365 exposure, checking whether employees recognize a fake login domain is only part of the problem. The assessment also needs to examine which authentication flows the organization permits and how it handles an unauthorized grant. Understand the decision behind the code Device authorization lets a user complete sign-in on another device for a client that cannot conveniently collect input itself. In a phishing scenario, the attacker supplies a code associated with the attacker’s client. The victim’s interaction with a legitimate identity provider can complete that client’s authorization. [Microsoft’s September 22 EvilTokens research](https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/) documents campaigns that abused this flow to obtain tokens and access organizational accounts. Employees need to verify which application or device they are authorizing, even when the sign-in page belongs to Microsoft. For example, a finance employee may receive instructions to enter a code to view a supplier’s revised invoice. That code can authorize a new client session. Before entering it, the employee should confirm the request through the supplier contact or invoice process they already use. Find the legitimate uses before changing policy Ask the identity administrator to identify current device-code use, the accounts involved, and the business owner for each case. Meeting-room hardware or a specific administrative tool may have a legitimate dependency. A broad exception for every employee is a different choice from an exception for a documented device group. [Microsoft’s authentication-flow documentation](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows) describes reviewing sign-in logs and using report-only Conditional Access policies to understand impact. It recommends allowing device code flow only where needed. Treat report-only results as impact evidence, not as proof that a blocking control is already active. For a review, produce a small exception register. Each exception needs a purpose, owner, scope, and review date. Ask what prevents an attacker from using the same exception with a different client or destination resource. If the answer is unknown, keep that uncertainty in the assessment rather than treating the exception as automatically safe. Test the policy with accounts created for the assessment Use a test identity, synthetic mailbox content, and an approved test client. Establish a permitted baseline, then exercise a flow the policy is intended to deny. Do not ask an employee to authorize a real attacker-controlled application as a demonstration. Keep results for both the permitted and denied cases. The legitimate device workflow should still work, and the excluded client should fail to obtain a session. A policy screenshot helps explain the setup; the test results show what happened. This creates two meaningful outcomes: legitimate business access remains possible, and the excluded path is rejected. A screenshot of a policy’s configuration establishes intent. These results establish its behavior for the tested cases. Rehearse containment beyond a password change If unauthorized access occurs, the response owner needs to consider issued sessions, refresh tokens, added authentication methods, application permissions, and activity in the affected services. The correct actions depend on the evidence and the identity platform’s behavior. Do not assume resetting a password proves every issued access path has stopped. For a tabletop exercise, create a synthetic timeline with a sign-in, mailbox access, and a suspicious rule change. Ask the team to identify which logs it needs, who can revoke access, and how it would verify containment. Check the retention period before an incident, since a missing log cannot be recovered by writing a better response procedure later. Measure the handoff between help desk, identity administrator, and incident response. The employee’s report needs a route to someone with the authority to investigate. A technically correct control can still leave a damaging delay if every team expects another team to act. Where this fits in a Ceron assessment For Ceron, agree whether the engagement covers identity configuration, an authorized authentication-flow test, or the customer application that trusts the resulting identity. These scopes require different access and evidence. A website’s HTTPS or security-header results do not establish whether Microsoft 365 sign-in policies are effective. The report should list permitted flows, exceptions, observed policy decisions, and the containment exercise results. Assign unresolved items to an owner and specify the test required to close each one. A genuine login page can authorize access for the wrong client. Include that case in employee guidance and in the tests of your sign-in policy. Further Ceron reading [Session revocation after compromise](https://getceron.com/blog/session-revocation-after-account-compromise) explains why issued access deserves separate verification. The finance and incident scenarios above are illustrative assessment designs. ### Browser Patch Management: Prove the Fix Is Running on Business Devices URL: https://getceron.com/blog/browser-patch-management-security-verification Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-26T00:00:00-07:00 Browser Patch Management: Prove the Fix Is Running on Business Devices Your device dashboard says a browser update was delivered. An employee’s laptop says a restart is pending. The browser holding the company’s CRM, payment portal, and administrative sessions has been open for two weeks. Which of those states does the security report describe? Check that devices are running the release that fixes the issue. A downloaded update can sit unused until the browser restarts, so delivery records alone can leave you with an incomplete patch report. Identify the release channel before declaring a device patched Browser fleets can include ordinary stable releases, extended stable releases, managed devices, and mobile installations. Compare each device with the vendor guidance for its channel and platform. A version number copied from an announcement for another channel can create a misleading exception or a misleading pass. [Google’s September Chrome release archive](https://chromereleases.googleblog.com/2026/09) lists separate updates for desktop stable, extended stable, mobile, and ChromeOS. Match each device to the announcement for its own platform and channel before marking it patched. For a controlled review, select a representative device from each supported platform and channel. Record the installed version, the running version where it can be established, the policy source, and the last observation time. If an inventory tool reports only installed files, document that limitation before interpreting the result as proof about an active browser process. Give relaunches an owner and a deadline [Chrome’s enterprise relaunch guidance](https://support.google.com/chrome/a/answer/7679871?hl=en) describes recommended and required relaunch notifications for pending updates. These options differ in what the employee can defer. An organization should choose a policy that fits the risk and the work people must preserve. Suppose a dispatch team keeps its scheduling application open across shifts. IT delivers browser updates overnight, but the devices rarely restart the browser. Agree a relaunch window at shift handover, with a way to save work and reopen the application. Check that the updated browser is actually running afterward. Test the selected behavior on a designated device. Confirm that the notification appears, that the deadline behaves as configured, and that the browser returns to the expected application state afterward. Keep the normal task in the acceptance test. A policy that interrupts a critical workflow without a usable recovery procedure will produce pressure to exempt the entire team. Count the devices your report cannot see The denominator matters. A report showing 98 percent compliance is difficult to interpret if it excludes contractors, infrequently connected laptops, or an acquired company’s devices. Define which systems can reach the business applications in scope and reconcile that population with the managed-device list. Treat stale observations as stale. If a laptop last checked in before the relevant release, the report cannot prove its current version. Give that device an owner and a way to restore visibility. Where access policy depends on current device status, verify the actual application behavior instead of assuming a device label automatically limits access. Separate unsupported systems from delayed updates. The first may require replacement or a different approved platform. The second may require a relaunch, repair of the update mechanism, or a documented scheduling exception. Combining them into one backlog conceals the decision each owner needs to make. Prioritize by the authority the browser carries A browser used only for a public information kiosk and a browser holding cloud administration sessions have different consequences if compromised. Use that context when assigning review urgency and exceptions. Include privileged workstations, finance users, support teams, and devices that handle confidential customer files. Patching does not establish that an earlier compromise did not occur. If there is evidence of suspicious activity, the response must address affected sessions and credentials separately. Likewise, a fully updated browser does not prove every extension or web application it uses is safe. Keep those boundaries visible in the report. Use the device’s access when setting urgency. An overdue browser on a cloud administrator’s workstation may need attention before one on a public kiosk. The report should show both the running release and the applications each device can reach. What Ceron can help establish within an agreed scope For a Ceron review, define whether endpoint evidence is available and whether the work covers browser policy, access to privileged applications, or the website itself. A public website assessment and a managed-browser review answer different questions. Supply the evidence necessary for the boundary you want verified. Ask for a result organized around verified running releases, unobserved devices, and exceptions with named owners. Set the closure condition before remediation: a fresh observation of the appropriate release, a completed relaunch where required, and confirmation that the intended business workflow still operates. Keep devices with stale or missing observations visible in the patch report. Management needs to know how many devices are confirmed current, how many still need a relaunch, and how many have not been checked. Related Ceron assessment topics [Browser extension access](https://getceron.com/blog/browser-extension-access-business-applications) covers an adjacent source of business exposure. [Critical CVE response](https://getceron.com/blog/a-critical-cve-affects-your-technology-stack-do-you-need-a-security-assessment) explains assessing affected versions and actual reachability. The dispatch example above is illustrative. ### AI Crawler Security Settings: Keep Your Business Website Discoverable URL: https://getceron.com/blog/ai-crawler-security-settings-website-discoverability Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-22T00:00:00-07:00 AI Crawler Security Settings: Keep Your Business Website Discoverable Your marketing team wants customers to find the blog. Your security team wants to control automated access. A crawler setting can affect both, so check which visitors and pages it covers before changing it. Crawler access belongs in a website security review because the setting can alter availability for an important audience. It also belongs in an SEO review because a perfectly written article cannot be discovered through a crawler that the delivery layer refuses to serve. Define search, training, and agent access separately Write a short business policy for each purpose. Public articles may be intended for search discovery. The company may make a different choice about training use or an agent fetching pages for a user. Customer portals and confidential exports require authorization regardless of any crawler preference. [Cloudflare’s September 15 crawler-control explanation](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/) distinguishes Search, Training, and Agent settings. It also explains that blocking mixed-use crawlers can affect search, while its Disallow AI Training setting is designed to preserve eligible search access. Those are provider-specific behaviors to verify in the actual configuration, not assumptions to carry into every hosting platform. Read the rules currently applied to the production domain, including any older settings and custom rules. Record the response they produce. The label on a dashboard setting may not explain why a crawler is being blocked. Follow the request through the delivery path Inspect robots.txt, the sitemap, page-level indexing directives, canonical URLs, and the edge controls serving the page. These mechanisms answer different questions. A robots allowance does not override a firewall rejection. A successful HTTP response can still include a directive asking a search engine not to index the content. Test the home page, blog index, an article, and a protected customer route. Public pages should return their content and intended metadata; the customer route should still require sign-in. Check each result after changing a delivery rule. Retain response status, relevant headers, initial HTML, and the rule decision where available. Compare the delivered canonical with the URL submitted for discovery. An obsolete domain, temporary preview hostname, or redirect chain can create uncertainty even when the final page looks fine in a browser. Use real crawler evidence for the final conclusion Changing a request’s User-Agent can help identify simple response differences, but it does not prove that a verified crawler receives the same treatment. Some delivery services classify visitors using additional signals. A test that labels itself Googlebot is therefore only one diagnostic observation. Use Search Console’s URL Inspection and live test where available, and correlate its result with delivery logs or verified bot events. The live test can establish whether Google can currently fetch the selected page. It does not guarantee that Google will choose to index it or rank it for a particular query. [Google’s recrawl guidance](https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl) explains that crawl requests and sitemap submission help discovery without guaranteeing inclusion. Keep the distinction in the acceptance record. Technical eligibility is a result you can test; a future ranking is not a result an assessor can promise. Keep confidential information behind authorization Crawler preferences govern requested use of content or access by classified automation. They are not a replacement for customer-account permissions. If a private export is available to anyone holding a link, discouraging crawlers does not establish that only the correct customer can retrieve it. Review protected paths with synthetic accounts and records. Confirm that public delivery rules do not accidentally serve a saved export or authenticated page from a shared cache. Keep the private-route tests separate from marketing’s discovery checks, with an owner for each boundary. This matters when a team fixes an indexing problem by relaxing a broad rule. The desired change should be specific to the intended public audience and paths. Verify the protected application again after the change rather than assume its behavior is unaffected. Include discovery in Ceron’s website assessment acceptance For Ceron, scope the public domain, delivery layer, and sensitive application paths that share it. Identify who can supply Search Console evidence and who owns the CDN configuration. If one layer cannot be inspected, state the limitation and retain the evidence available from the delivered responses. Keep the crawler policy, public-page responses, sitemap coverage, indexing directives, and private-page access tests in the handover. Name who can change CDN rules and who reviews the effect on search discovery. After a rule change, verify that crawlers can fetch the public articles and that customer records still require authorization. These two checks help security and marketing assess the same configuration. Related Ceron guidance [The website security check guide](https://getceron.com/blog/how-to-check-if-your-website-is-secure) explains the limits of external checks. [The private cache assessment guide](https://getceron.com/blog/cdn-cache-private-customer-data) covers customer information at the delivery layer. The business website scenario above is illustrative. ### Passkey Security: Assess the Help Desk and Enrollment Path URL: https://getceron.com/blog/passkey-security-help-desk-enrollment-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-19T00:00:00-07:00 Passkey Security: Assess the Help Desk and Enrollment Path A company deploys passkeys and expects its account-takeover risk to fall. Then an employee gets a call claiming to be the help desk, asking them to repair their new security setup. The important decision is no longer whether the employee types a password into a fake site. It is whether the person giving instructions has authority to change the employee’s access. Review enrollment, recovery, method replacement, and support alongside normal passkey sign-in. Anyone who can change those settings may be able to decide who gets into the account next. Identify which step the attacker is trying to influence [Microsoft’s September 9 research on passkey-themed social engineering](https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/) describes lures that led to several cloud-identity compromise paths, including device code phishing. A passkey theme in a message does not establish that the cryptography of passkeys was broken. The route the victim was induced to use matters. For a business review, separate theft of an existing secret, authorization of another client, addition of an authentication method, and abuse of recovery. Each involves a different control and a different closure condition. A report that labels all four passkey bypass hides the action the identity team needs to take. Suppose a professional-services firm requires passkeys for administrators but lets the help desk reset methods after a few biographical questions. An attacker may target that reset process instead of the passkey. Include the help desk procedure in the assessment. Treat enrollment as a privileged change Map who can add a method, what evidence is required, and whether the account owner receives an independent notification. Record the administrator roles that can intervene and the logs that record their actions. Include the process for a user who has lost every approved method. Use a synthetic account to test the actual enrollment path. Establish the required verification, add an approved test method, and check the resulting account state and notification. Then try the designated negative case, such as a support operator without the required role or a request that has not completed the specified verification. Keep the result of the denied enrollment attempt and the audit record for the approved one. Verify who can confirm a method change; the presence of a confirmation screen does not answer that question. Give employees a way to verify the help desk Create a support route employees can initiate themselves, using a known portal or established contact. The process should connect a request to a real ticket and an authorized operator. Do not make the employee rely on caller ID, a chat display name, or information a stranger could find publicly. Rehearse the route with a fictional support request. Measure how long it takes to verify the request and what happens outside normal support hours. If the process is too cumbersome for legitimate help, correct that friction. People will follow the route that allows them to continue working. The help desk also needs protection from pressure. Define what evidence it must collect, which exceptions require a second reviewer, and how to handle an urgent executive request. An exception should remain attributable to a person and a case, rather than become an undocumented administrative habit. Check fallback paths with the same account roles After confirming normal passkey sign-in, inventory the other ways the same account can gain access or replace a method. Include recovery codes, legacy methods, support overrides, and delegated administrative actions where the platform provides them. Determine which remain available to privileged users. Test fallback behavior in the designated environment. If a strong method is required for a sensitive application, verify the result when a permitted weaker method is used elsewhere. Do not assume the requirement on one sign-in page applies to every application or every recovery path. Also test retirement. Remove a test method and confirm that it no longer permits a new sign-in. Review how existing sessions are handled under the organization’s policy. These are different states, and the report should say which was verified rather than imply method removal erases all prior access. Scope the evidence Ceron needs A Ceron identity review should specify the tenant, account roles, authorized test identities, and enrollment and recovery procedures available for assessment. If the engagement covers a customer application using an external identity provider, also verify how that application handles role changes and account disablement. The deliverable should show the normal sign-in path, the fallback paths, the people who can change methods, and the results of approved and denied changes. Recommendations should name the process owner as well as the technical owner. Otherwise a configuration fix can leave the support exception untouched. When you close a passkey rollout, include evidence for recovery and help desk changes as well as successful sign-ins. A weak reset procedure can leave privileged accounts exposed after the rollout is complete. Continue the Ceron identity review [Passkey rollout and account recovery](https://getceron.com/blog/passkey-rollout-account-recovery) covers planning the lifecycle. [Emergency administrator access testing](https://getceron.com/blog/emergency-admin-access-testing) addresses controlled exceptions. The firm and help desk exercises above are illustrative. ### GitHub Actions Cache Poisoning: Assess What Your Release Build Trusts URL: https://getceron.com/blog/github-actions-cache-poisoning-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-16T00:00:00-07:00 GitHub Actions Cache Poisoning: Assess What Your Release Build Trusts A release build restores a dependency cache to save time. The team recognizes the repository and the workflow, so the restored files are treated as ordinary build inputs. The security question is who could have influenced those files before the release job used them. Software supply-chain assessment has to follow inputs as well as credentials. A job can protect its publishing token and still trust material produced under weaker controls. Caches belong in that review because they connect executions that may have different levels of authority. Cache permission is part of release permission [GitHub’s September 10 cache-mode release](https://github.blog/changelog/2026-09-10-control-github-actions-cache-access-with-cache-mode/) adds workflow and job controls for cache access. The documented modes are read, write, write-only, and none. GitHub also notes that explicitly granting writes to low-trust events can override their read-only default and increase poisoning risk. Decide which jobs need to read a cache and which can write one. Check every cache a release job restores, including who created it. A faster build is useful only if the restored files are suitable inputs for the release. Inventory permissions at the job level, including reusable workflows. Keep cache permissions separate from repository-token permissions in the assessment record. One controls cache operations; the other governs a different set of capabilities. A restrictive repository token is not evidence that cache behavior was examined. Trace the file that reaches the shipped artifact Start at the final package, image, or website bundle and work backward. Identify restored directories, generated files, dependency installation steps, and commands that execute restored material. Record which inputs are verified or rebuilt before packaging. Suppose a SaaS pipeline caches dependencies and a generated application bundle together, then packages the restored bundle without rebuilding it. Check whether a less trusted job can supply those files. Review the actual event scope, cache visibility, keys, and workflow settings; cache sharing differs across branches and events. Broad restore prefixes deserve attention because they can select material beyond the most specific expected key. Explain why each fallback exists and which producers can create matching entries. Where a boundary cannot be established from configuration alone, use a controlled test rather than declaring exposure from a naming pattern. Test cache behavior with harmless markers Use a designated repository or authorized test branch and a cache namespace created for the assessment. Place a unique, non-executable marker in a test producer’s output. Run the relevant consumer under the intended event and permission combinations, then check whether the marker appears in the restored directory or final test artifact. The test should establish both reachability and consequence. A marker restored into an unused directory is different from a marker included in a package. Record the event, permissions, cache key, restore result, and artifact inspection. Do not put malicious code into a real release pipeline to prove a trust boundary. Add a negative case for a producer that should not be able to save a cache. The useful result is an enforcement rejection with evidence from the cache operation. A job failing earlier for an unrelated reason does not demonstrate that cache permissions held. Review release credentials alongside the inputs When a build executes restored tools, the authority available during execution matters. Identify publishing tokens, cloud credentials, and write permissions present in that job. Decide whether those credentials are required throughout the job or only during a narrow release step. Review build inputs and publishing permissions together. Rebuilding from reviewed source can remove reliance on a cached bundle. Restricting publishing credentials limits who can release it. Record the evidence for each control and any gaps between them. Also include the emergency workflow. A carefully configured normal pipeline can coexist with a manually triggered job that restores broader inputs or uses an old publishing secret. Give the emergency path the same ownership and evidence requirements as the routine one. What a Ceron supply-chain assessment should establish Agree which repositories, workflow events, and publishing destinations are in scope for a Ceron engagement. Provide read access to relevant configuration and an authorized environment for behavioral checks. The public customer website alone cannot show who populated a CI cache. Useful findings identify an actual producer-to-consumer path, the permissions involved, and the material consequence. Retesting should repeat the original marker case and confirm that the normal release still works. Document the performance cost of disabling or narrowing a cache so the business can make the change knowingly. Keep caching where it helps, but document which jobs can populate each release cache and how the release validates what it restores. Repeat those checks when workflow events or permissions change. Related Ceron supply-chain guidance [GitHub Actions pull request boundaries](https://getceron.com/blog/github-actions-pull-request-trust-boundaries) covers event trust. [Artifact attestations](https://getceron.com/blog/artifact-attestations-what-provenance-proves) explains what build provenance can establish. The pipeline and marker tests above are illustrative. ### npm Account Recovery Security: Protect the Emergency Release Path URL: https://getceron.com/blog/npm-account-recovery-release-security Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-12T00:00:00-07:00 npm Account Recovery Security: Protect the Emergency Release Path The team needs to ship a security fix, but the only available maintainer has lost access to their normal authentication method. A recovery code gets them back into the account. The release meeting treats that as a support issue solved, while the registry treats it as a security-sensitive transition. Plan for account recovery before an urgent release. A maintainer who regains account access may still be unable to publish, and an alternate release route needs its own approval and access controls. Know what recovery changes in the registry [npm’s September 9 recovery-code update](https://github.blog/changelog/2026-09-09-npm-extends-recovery-code-security-holds-to-all-accounts/) applies a 72-hour hold after successful recovery-code sign-in to all accounts. During the hold, publishing and certain sensitive writes, including token creation, are paused, while browsing and package installation remain available. The hold expires automatically. This is a concrete dependency to include in the release plan. Do not promise an immediate publish from a recovered account without checking its current restrictions. If an unexpected hold appears and the maintainer did not initiate recovery, npm advises contacting support. Investigate that signal instead of assuming it is merely a deployment inconvenience. Identify the people behind every publishing path List package maintainers, organization owners, trusted publishing workflows, and any remaining release tokens. Record who controls each identity and how the team removes authority when someone leaves. Match the inventory with the registry and CI configuration rather than rely only on an internal spreadsheet. A company might automate releases for its main package while leaving a legacy plugin with one human maintainer. Check every published product: the plugin may depend on that person’s device even when the main release has a tested backup. Avoid solving the dependency by making every developer an owner. The alternative is a deliberate set of authorized maintainers, protected authentication, and a tested backup route whose authority is limited to what it needs. Name the people responsible for keeping that route current. Store recovery material as authority over the release A recovery code should be handled according to what the account can do. If that account can distribute software to customers, recovery material deserves controls suitable for that authority. Specify the approved storage system, access rules, and procedure for legitimate use without copying the codes into an assessment report. For review, ask for evidence that access is limited to the intended custodians and that the recovery procedure can be initiated when a maintainer is unavailable. Use metadata and access-control evidence, not live secrets. The report can describe where material is governed without reproducing it. Also review dependencies outside npm. If the account’s email recovery is weak, registry recovery protections do not resolve that separate route. Map the email account, authentication methods, and administrative reset authority. The assessment should identify the boundary it verified and the ones requiring another owner’s evidence. Rehearse an urgent fix without bypassing the controls Use a tabletop scenario in which the primary maintainer is unavailable and the release account is temporarily restricted. Ask which authorized route can still ship, who reviews the source and artifact, and how the team communicates the delay internally. Do not disable protection on a production package as a drill. If a behavioral exercise is necessary, use a designated test package and follow the registry’s published rules. Establish the baseline, record the restriction, and verify the approved alternate path. Schedule the exercise so the expected hold does not surprise the real release team. Keep artifact approval attached to the exact version being released. An emergency sign-off on a source change should not silently authorize a later rebuilt package with different contents. Record the artifact identifier, reviewer, destination, and actual publish result in the release evidence. Detect recovery events that nobody expected Define who receives account-security notifications and how those messages reach a responder. A warning sent to a former employee’s mailbox is a weak control even if the registry generated it correctly. Verify recipients and handoffs as part of the maintainer review. Create a synthetic alert for the tabletop exercise. Ask the responder to identify the account owner, determine whether recovery was legitimate, and assess whether release credentials or ownership changed. Record the information the team could obtain and how long it took. Check whether the responder can identify who requested recovery and whether it was authorized. If that takes too long, fix the account ownership record and alert handoff before the next release. Define Ceron’s release-security deliverable For a Ceron assessment, scope the package registry, release workflows, human maintainer roles, and recovery dependencies explicitly. Identify which settings can be inspected and whether testing uses a separate package. Preserve production release continuity while establishing the boundary. The handover should include the effective publishing inventory, single-person dependencies, expected recovery restrictions, and the result of an emergency release rehearsal. Give each gap an owner and a retest condition. A registry protection is most useful when the business knows how to work within it. Keep the recovery procedure with the release documentation and rehearse the backup route. During an urgent fix, the team should already know who can publish and which restrictions may delay them. Related Ceron reading [Service account ownership and retirement](https://getceron.com/blog/service-account-ownership-and-retirement) covers durable accountability. [npm trusted publishing controls](https://getceron.com/blog/npm-trusted-publishing-release-controls) reviews automated release authority. The company and emergency scenarios above are illustrative. ### npm Staged Publishing: Verify What a Maintainer Actually Approves URL: https://getceron.com/blog/npm-staged-publishing-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-09T00:00:00-07:00 npm Staged Publishing: Verify What a Maintainer Actually Approves A pipeline builds a package and a maintainer approves the release. Before relying on that approval, check what the maintainer saw: the source commit, a workflow result, or the exact package customers will install. Staged publishing can create a valuable decision point in the release process. A supply-chain assessment needs to establish that the decision applies to the intended artifact and that another route cannot publish around it. Understand the boundary the registry provides [npm’s staged publishing release](https://github.blog/changelog/2026-05-22-staged-publishing-and-new-install-time-controls-for-npm/) describes uploading a prebuilt tarball to a queue before a human maintainer approves it with a two-factor challenge. Its documented setup supports stage-only trusted publishing, so an automated workflow can prepare a release while direct publishing from that configuration is rejected. Those are distinct authorities: producing a candidate and making it available to consumers. Review both in the actual account. An approval requirement on one workflow does not establish that every maintainer, token, or legacy process has the same restriction. Follow the artifact from build to approval Record the reviewed source commit, workflow identity, build inputs, package version, tarball identifier, and destination registry. Establish how a reviewer confirms that these describe the candidate in the queue. If the approval screen omits information your release policy depends on, identify where the reviewer gets it. Suppose a client-library build downloads a generated component from another service. The reviewer approves the repository change, but that approval does not account for the downloaded component. Keep evidence of its origin and version with the candidate package. Inspect a designated candidate package before release. Compare its files with the expected distribution: compiled code, types, documentation, and other required assets. Check for unexpected configuration files or development material. The purpose is to make the candidate understandable, rather than infer its contents from a successful build badge. Review what the staging identity can still change A staging credential may have access beyond creating a candidate. Inventory its effective permissions and the workflow conditions under which it is available. Determine who can change the workflow, replace build inputs, or alter the publishing configuration. Check who can change the rule requiring approval. Automation that can remove its own publishing restriction may still release without a reviewer. Record that administrative permission separately and test it in the agreed environment. Keep credentials out of screenshots and reports. Non-secret identifiers, permission descriptions, sanitized operation results, and artifact hashes can establish the relevant relationship without distributing release secrets. Test both the gate and the route around it Use a designated test package and an authorized workflow. Create a candidate without approving it and confirm that it is not available for ordinary installation under the expected package version. Then approve the exact candidate and verify the resulting artifact. Retain registry responses and the package identity at both stages. Next, exercise a direct publish using the identity that is intended to be stage-only. The expected result is rejection. A workflow convention that normally runs a staging command is weaker than the registry denying direct publication from that identity. Review older tokens, human publishing rights, alternate CI providers, and emergency jobs separately. If an authorized direct-publishing route remains, document its purpose and governance. A useful assessment identifies the exception openly rather than claiming every release is gated because the main pipeline is. Make the approval useful under release pressure Give reviewers a short acceptance procedure: confirm the package and version, match the candidate to the reviewed change, inspect relevant artifact evidence, and verify the destination. Define when a second reviewer is needed based on the organization’s risk, not because more clicks automatically mean more security. Rehearse rejection as well as approval. A suspicious candidate needs a clear owner, an investigation route, and a way to prevent an accidental release while the team checks it. Confirm that a rejected candidate cannot quietly return through the alternate publishing path. Also test an urgent legitimate release. Identify the available approver, authentication requirements, and the evidence that remains mandatory. The emergency plan should preserve the boundary the company adopted, with a documented decision if an exceptional route is genuinely required. What Ceron should establish for your package release For a Ceron supply-chain engagement, agree the packages, registry accounts, workflows, and test environment in scope. The assessment needs visibility into both the candidate-producing path and the identities that can make a release public. Testing only the finished customer application cannot establish those controls. The report should connect the approved artifact to the installed result, show whether direct publication was denied, and identify remaining exceptions. After remediation, repeat the gate and bypass tests and verify that normal release work still completes. Before accepting staged publishing as a release control, confirm that approval applies to the package customers receive. Test direct publishing from the staging identity and document any other identities that can still bypass the queue. Related Ceron assessment guidance [Artifact attestations and provenance](https://getceron.com/blog/artifact-attestations-what-provenance-proves) explains the evidence connecting source and builds. [Leaked secret remediation](https://getceron.com/blog/leaked-secret-remediation-beyond-git-deletion) covers a publishing credential that escapes its intended boundary. The client-library and test-package examples above are illustrative. ### When Business Documents Become Instructions for an AI Assistant URL: https://getceron.com/blog/prompt-injection-in-business-documents Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-17T00:00:00-07:00 When Business Documents Become Instructions for an AI Assistant An assistant reviewing supplier proposals has to read material the company did not write. That creates a security question before the assistant takes any action: can text inside a proposal influence how the assistant uses the company's systems? A document can contain both useful facts and instructions aimed at the software reading it. This is indirect prompt injection: instructions reach the assistant through material it was asked to read. The damage depends on the assistant’s permissions and whether another part of the application checks its actions. How document content crosses a trust boundary OWASP distinguishes direct prompt injection from instructions encountered through external content. A model can treat material from a file or website as direction rather than evidence. Retrieval and fine-tuning do not, by themselves, eliminate that possibility. [OWASP's prompt injection overview](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) explains this distinction. Suppose an assistant compares three supplier proposals. One proposal says the review requires a separate internal pricing file. The supplier has no right to that file just because it asks for it. The application should keep the comparison limited to the documents the user authorized. The connected systems determine the consequence A summarizer with access only to the uploaded proposals has a different exposure from one that can search the finance drive and email attachments. The first may produce an inaccurate comparison. The second may also attempt an unauthorized disclosure. These outcomes require different controls and different evidence. For a document review service, map the available tools to actual business needs. A comparison task might require reading selected files and saving a draft. Sending messages, changing supplier records, or retrieving unrelated customer contracts introduces separate authority. The tool service can enforce those boundaries even when the model proposes an inappropriate action. A controlled test with a measurable result Use a test workspace containing synthetic proposals and a uniquely labeled internal document. Establish a normal comparison result first. Then introduce a harmless instruction into a proposal that asks the assistant to include the internal label or perform an out-of-scope action. Keep all destinations and accounts under the test team's control. Record more than the final answer. Capture which documents were retrieved, which tools were requested, which requests were denied, and whether an approval was presented. A model refusing the instruction once demonstrates behavior in that trial. A downstream service consistently denying access provides evidence about the permission boundary. What the business can verify before release The resulting assessment can identify the content entry point, the authority available to the assistant, and the control that prevented or permitted the action. That is more specific than labeling an entire product vulnerable because it produced an unexpected sentence. Repeat these cases after changing connectors, permissions, or document parsers. Include ordinary proposals so you can confirm that comparisons still work. Keep the retrieved files and attempted operations with each result; they show whether access controls held even when the model followed a document’s instruction. Sources [OWASP: LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html). The procurement example and test design above are illustrative applications of the documented risk. ### AI Agent Permissions: Defining What a Business Workflow May Change URL: https://getceron.com/blog/ai-agent-permissions-business-workflows Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-03T00:00:00-07:00 AI Agent Permissions: Defining What a Business Workflow May Change An AI assistant that can explain an invoice and an agent that can approve one operate under different levels of authority. The visible conversation may look similar, but the second system can change a business record. Security review therefore needs to examine the operations available behind the chat interface. Start with a specific finance task. Who can issue a refund? Which payment can they refund, and what must the payment service check first? A general instruction to help the finance team leaves these decisions unresolved. Excessive agency has several causes OWASP describes excessive agency in terms of unnecessary functionality, excessive permissions, and excessive autonomy. These are separate design choices. A tool can expose too many operations, a credential can authorize too many resources, or an otherwise appropriate operation can execute without a required decision. [OWASP's excessive agency guidance](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) sets out these distinctions. A collections assistant may need invoices and correspondence to draft reminders. It has no reason to change bank details. Leaving that operation out of its tool list reduces the access available during a reminder task. Translate policy into service-side checks For each write operation, describe the actor, target record, permitted change, and required preconditions. A refund might require an eligible payment, a remaining refundable balance, and a reviewer with the appropriate role. The service processing the refund can evaluate these conditions independently of the model's explanation. User context also matters. A shared administrative credential can make every assistant user appear equally privileged to the downstream system. Carrying the authenticated user's identity and tenant scope through the request allows the service to apply the same business restrictions used elsewhere in the application. Make approvals specific to the action An approval is more informative when it identifies the exact record and proposed change. For a refund, that means the payment, amount, currency, and destination. If the agent changes those details after approval, the original decision no longer describes the operation being executed. In a test environment, approve one synthetic refund and then alter a material field before submission. The expected result is a fresh decision or rejection. Also try replaying the original approved request. The ledger and event history can establish whether one approval resulted in one permitted business change. Document the authority that was exercised The assessment record can connect the user request, proposed operation, approval, service authorization, and final state. Include denials and timeouts as well as successful actions. A stalled workflow that later resumes may otherwise execute under permissions or business conditions that have changed. Before release, verify that the agent can prepare the task, obtain approval for the exact change, and submit it under the user’s account permissions. Add a new test when you give it another operation. Sources [OWASP: AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html). The invoice and refund scenarios are illustrative, not reports of a customer incident. ### RAG Access Control: What Happens When Document Permissions Change? URL: https://getceron.com/blog/rag-access-control-after-permission-changes Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-21T00:00:00-07:00 RAG Access Control: What Happens When Document Permissions Change? A document search assistant may answer from a copy of information rather than the original file. The source document can lose a reader while its extracted text remains in a search index, a conversation, or an answer cache. A permission change therefore has to be understood across the entire retrieval path. Retrieval-augmented generation, or RAG, supplies selected documents to a model when it answers a question. The retrieval service must check who can read those documents, including after permissions change at the source. Search relevance does not establish permission An embedding helps a system find material related to a question. It does not establish whether the person asking may read that material. OWASP identifies unauthorized access and cross-context disclosure among the risks of shared vector stores. [Its vector and embedding guidance](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/) calls for permission-aware retrieval and separation between access groups. Consider a synthetic acquisition folder restricted to a small review team. An employee initially belongs to that team and can ask the assistant questions about the folder. After removal, a search result that still includes extracted paragraphs could disclose information even if the original document link now returns an access error. Follow each copy of the document Map ingestion, chunk storage, search filtering, model context, cached responses, and citation previews. Identify which component stores a permission snapshot and which checks the current source permission. Record how quickly a revocation is expected to propagate through each component. There is a practical distinction between preventing new retrieval and removing information already displayed to an authorized person. A permission change cannot make that person forget an earlier answer. It can prevent the service from serving new answers, reopened previews, or saved conversations that the product's access policy no longer permits. Test the transition, not only the initial setup Create two test users and documents with unique, non-sensitive phrases. Give one user temporary access, confirm a legitimate answer, then revoke access at the source. Repeat the same query and several paraphrases. Test both a new conversation and any supported shared or saved conversation view. Measure the time until unauthorized retrieval stops. Inspect the retrieved chunks as well as the generated response: a model might omit a protected phrase even though the retrieval layer improperly supplied it. That omission would not establish that the permission boundary worked. Define an operational acceptance condition An acceptance record can specify the permitted propagation delay, the affected indexes, and what happens while permission synchronization is unavailable. Failing closed for protected content may be appropriate where a current access decision cannot be established. The product owner also needs a clear user experience for unavailable results. Include folder moves, group changes, removal of external sharing, and employee departure in later checks. For each, keep a trace showing when the source permission changed and when retrieval stopped. Document any retained copies and how long they remain. Sources [OWASP: RAG Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html). The acquisition-folder example is a proposed test scenario using synthetic information. ### MCP Security: Why a Valid Token May Still Be the Wrong Token URL: https://getceron.com/blog/mcp-security-token-audience-and-tool-access Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-07T00:00:00-07:00 MCP Security: Why a Valid Token May Still Be the Wrong Token Connecting an assistant to an MCP server introduces an access path between the assistant, the server, and any business systems behind it. Authentication at one point in that path does not automatically establish authorization at every other point. The server has to know which identity is calling, what the credential was issued for, and which operation is permitted. Model Context Protocol standardizes how clients discover and use capabilities. A security review still needs to examine the particular server, its tools, and the identity flow used by that deployment. Audience is part of credential validation An access token can be correctly signed and unexpired while being intended for a different service. Accepting it without checking its intended resource can break the boundary between services. The MCP security guidance addresses token passthrough and requires appropriate token validation rather than treating an upstream token as universally usable. [The protocol's security practices](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices) describe these risks. For example, a document connector may let an assistant call an MCP server, which then calls a storage provider. Check both connections: how the assistant identifies itself to the server and how the server obtains permission to read the user’s storage account. Tool discovery also needs an ownership model Record who operates the server, where it runs, and who can change its tool definitions. A tool description tells the assistant how to use an operation; it is not a security policy that the downstream service can rely on. A renamed or newly expanded tool may expose different business capabilities. For local servers, installation permissions and process access are relevant. For remote servers, credential storage, tenant separation, and outbound requests are relevant. The assessment scope can identify these differences without assuming that every MCP integration uses the same hosting or authentication design. Test wrong-resource and wrong-user cases In a controlled environment, exercise a token intended for another resource, an expired credential, and a credential belonging to another test user. Confirm that rejection happens before any business data is returned or modified. Avoid putting complete tokens in the report; retain non-secret identifiers and sanitized validation results. Next, connect two test customer accounts and request a resource from the other account. A server that validates token format correctly may still select the wrong stored downstream credential. This is a tenant-binding problem, and it requires a different fix from signature or expiration validation. Evidence for a connector review The review can produce an identity-flow diagram, a list of tool capabilities, the accepted token issuers and audiences, and results for denied requests. Also document disconnect behavior: which grants are revoked, which credentials are removed, and whether existing sessions continue. Keep these records with the tested server version and configuration. Review them again when tools or identity handling change. Protocol compatibility alone does not show that the server rejects another customer’s credential or revokes access on disconnect. Sources [OWASP: MCP Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html). The document connector is illustrative; deployment-specific requirements depend on the protocol version and transport in use. ### AI Output Validation: From a Generated Answer to a Business Action URL: https://getceron.com/blog/validating-ai-output-before-business-actions Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-25T00:00:00-07:00 AI Output Validation: From a Generated Answer to a Business Action A model can return a well-formed object that still describes an unauthorized operation. A customer identifier can have the correct syntax while referring to the wrong customer. A payment amount can be a valid number while exceeding the amount the user is allowed to approve. When generated content enters another system, security depends on how that receiving system interprets it. The relevant checks include format, meaning, permissions, and the state of the business transaction. Format validation is one layer OWASP's improper output handling category covers cases where generated content is passed to downstream systems without appropriate scrutiny. Examples include unsafe rendering and execution. [The OWASP guidance](https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/) treats model output as untrusted input to those systems. A schema can establish that a proposed expense record contains a date, an amount, and a department identifier. It cannot establish that the receipt belongs to the claimant or that the department accepts the charge. Those are application decisions requiring authenticated context and business records. Separate proposals from execution An expense assistant can suggest a classification and save it for review. Keep that proposal separate from the approved ledger entry. Before recording the charge, the transaction service should check the claimant, cost center, currency, and approval state. This separation gives each component a defined responsibility. The model extracts and suggests. The application identifies the user and controls the workflow. The ledger enforces accounting constraints. A request does not acquire additional authority because its explanation sounds consistent with the receipt. Rendering is another interpretation boundary Generated text may become HTML, Markdown, a spreadsheet, or a database query. Each destination has different interpretation rules. Content that is harmless as plain text can become active markup or a formula when exported. Use the destination's established encoding and parameterization controls rather than a single generic cleanup step. For example, a report preview and its downloadable spreadsheet can require separate tests. The preview may display a synthetic string literally while the spreadsheet application interprets the same value. Testing only the browser would leave the export behavior unexamined. Verify rejected as well as accepted proposals Build controlled cases for a valid classification, an unknown cost center, a record from another test account, and an amount outside the configured approval limit. Also test missing fields and additional fields that the service does not accept. Record whether validation rejects the request without partially updating records. The model may produce different wording across repeated runs. The service's acceptance conditions can remain stable. An assessment can therefore distinguish variability in extraction quality from a failure to enforce the business rule. For release review, save the test input, proposed object, validation result, and final ledger state. Finance and engineering can use the same record to check what changed. Rerun the cases when the model, prompt, schema, or export library changes. Sources [OWASP: Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html). The expense workflow is an illustrative design and test example. ### AI Usage Limits Are Also Availability Controls URL: https://getceron.com/blog/ai-usage-limits-cost-and-availability Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-13T00:00:00-07:00 AI Usage Limits Are Also Availability Controls A document-analysis feature can accept one upload and create many downstream operations. It may extract pages, generate embeddings, retrieve related records, and run several model calls before returning a result. Counting incoming requests alone does not describe the resources the feature consumes. For a business offering AI functionality, usage controls affect both expenditure and service availability. One customer's large job can occupy capacity that other customers need, even when every request is authenticated. Account for the work behind each request OWASP includes unbounded consumption among its risks for LLM applications. The category covers uncontrolled resource use, including excessive inference and related operational costs. [Its guidance](https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/) discusses limits, monitoring, and controls across the processing path. A contract-review service may charge per document, but a two-page agreement and a scanned archive of hundreds of pages use very different amounts of processing. Track page count, extracted text size, model usage, elapsed time, and concurrent jobs as well as document count. Retries can change the workload A timeout does not always mean the underlying task stopped. If the client resubmits while the original job continues, the service may perform the same expensive work twice. Automatic retries between internal services can add further duplication. Assigning a stable job identity lets the application connect retries to existing work. Define which failures permit retry, how many attempts are allowed, and when the job becomes terminal. A cancellation request also needs a documented meaning: whether it stops queued work, signals running workers, or simply stops the user interface from waiting. Test limits without generating a production incident Use a dedicated environment with synthetic documents and a small explicit spending ceiling. Submit a normal document, a document near the supported size limit, and several simultaneous jobs from one test tenant. Then submit work from a second tenant and observe whether it receives its expected share of capacity. Introduce a controlled downstream timeout and inspect the number of actual processing attempts. Compare the front-end status, queue state, provider usage records, and internal job log. These records can reveal work that continues after the application reports cancellation or failure. Tie the result to a product decision The product owner can define an allowed workload for each account and an understandable response when that boundary is reached. A queue, a deferred job, and a rejected request are different service behaviors. The customer-facing message should match the action the system actually takes. Record how much work each test request created, where each limit was enforced, and what happened when two tenants competed for capacity. Use those results for capacity planning. Repeat the checks after adding tools, longer context, batch processing, or retries, since each can increase the work behind one upload. Sources [OWASP: Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html). The contract-review service and workload tests are illustrative. ### AI Prompt Logs: Where Business Data Goes After the Answer URL: https://getceron.com/blog/ai-prompt-logs-sensitive-business-data Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-01T00:00:00-07:00 AI Prompt Logs: Where Business Data Goes After the Answer A customer support assistant may process a short conversation while its observability systems retain the full prompt, retrieved account details, and model response. The application has then created another copy of the information it was asked to use. That copy can have different readers and a different retention period from the original support record. Reviewing AI data handling therefore includes the operational tools around the model. Debug traces, error reports, evaluation datasets, and exported conversations can all extend the data flow. Identify the information in each trace OWASP identifies sensitive information disclosure as a risk for LLM applications, including exposure through application context and downstream handling. [Its sensitive information guidance](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) provides the technical background. Whether a particular provider stores or uses submitted data requires checking that provider's actual configuration and applicable terms. List the fields a support assistant adds to its prompt: customer name, order history, internal notes, and attachments. Check which fields reach the debugging platform. For some faults, a request identifier is enough to investigate without copying the conversation and its source files. Retention settings need a data map A setting that deletes chat history may apply only to the product's conversation store. A separate trace service, backup, or quality-review export can follow another lifecycle. Record each location, its owner, its deletion mechanism, and whether it receives data directly or through a copy. This map also makes access review more specific. An engineer may need timing and error information while a support specialist needs the customer conversation. Granting both groups access to full prompt traces can expose more information than either task requires. Use synthetic markers to verify the path Insert a clearly labeled test value into a synthetic support case. Run the normal workflow, trigger a controlled error, and export the supported diagnostics. Search the known logging and evaluation destinations for the marker. This checks the actual handling path rather than relying only on a settings screen. Next, apply the configured deletion procedure and repeat the search after the documented processing period. Record destinations that are intentionally retained and those that failed to remove the data. A test result can establish observed behavior for the inspected systems, while the inventory identifies systems that still require verification. Preserve useful operational evidence Reducing content logging does not require removing all diagnostic information. Request identifiers, model configuration, timing, tool names, authorization results, and error categories may be enough for many investigations. Where full content is necessary, a restricted, time-limited diagnostic process can make that exception explicit. For each logging destination, document why it needs the information, who can read it, and when it is deleted. Test those settings against actual traces. A general AI privacy statement cannot establish how a separate debugging service handles your prompts. Sources [OWASP: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html). The support workflow is illustrative and does not describe a specific provider's retention policy. ### A Model Download Is Part of the Software Supply Chain URL: https://getceron.com/blog/model-downloads-software-supply-chain Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-31T00:00:00-07:00 A Model Download Is Part of the Software Supply Chain Deploying a downloaded model involves more than choosing weights. The deployment may include a tokenizer, configuration files, custom loading code, dependencies, and an inference container. Each item has an origin and can change independently of the model's displayed name. For businesses evaluating self-hosted AI, the security review begins at acquisition. A successful benchmark does not establish how the artifact was obtained, what code loads it, or which permissions that code receives. File format changes the loading risk Some serialization formats can invoke code while loading. Hugging Face documents the risks associated with Python pickle files and explains the scope of its scanning. A scan result is a signal about inspection, not a guarantee that every possible behavior has been excluded. [Hugging Face's pickle security documentation](https://huggingface.co/docs/hub/security-pickle) describes this limitation. The review can record the exact artifact digest, repository revision, loader, and any requirement to execute custom code. These details distinguish a reviewed download from a later file published under the same project name. Data-oriented formats can reduce a particular loading risk while leaving surrounding code and dependencies in scope. Treat the first load as a deployment event Suppose a company evaluates a document classifier on a machine that also holds cloud credentials. Its loader may be able to use those credentials. Start unfamiliar models in an isolated evaluation environment with only the files and access the test needs. Document which network destinations the loader needs, which directories it can write, and whether credentials are present. A model that needs only local inference does not automatically need the same network and account permissions as the deployment pipeline that downloaded it. Preserve an approved artifact record Link the model revision to the inference code, container image, configuration, and evaluation results. Record licenses and usage conditions in the procurement process separately from technical security checks. A technically inspectable artifact does not settle all conditions for using it in a business product. If a deployment references a moving branch or tag, establish how changes are approved. Reproducing the exact evaluated combination becomes difficult when the model, dependencies, and loader all resolve to whatever is current at startup. Test the replacement process An assessment can follow one model from download to a staging deployment, checking the recorded hashes against the running artifact. It can also verify that an unapproved revision is rejected or requires a new review. Use harmless substitute artifacts for this control test rather than introducing malicious code. Check that the running model matches the approved package and that its loader has only the intended permissions. Record both results. Answer accuracy and training-data quality need separate evaluations. Sources [OWASP: LLM Supply Chain](https://genai.owasp.org/llmrisk/llm032025-supply-chain/). The classifier scenario is an illustrative deployment review. ### Knowledge Base Poisoning: Checking the Sources Behind an AI Answer URL: https://getceron.com/blog/ai-knowledge-base-poisoning-source-integrity Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-17T00:00:00-07:00 Knowledge Base Poisoning: Checking the Sources Behind an AI Answer An assistant can quote a document accurately and still return the wrong business instruction. If the underlying document was changed without authorization, faithful retrieval reproduces the unauthorized change. The security question sits in the knowledge pipeline as well as in the generated answer. Check the sources behind assistants that explain company procedures or customer obligations. A citation can point to a document that was changed without approval, so quoting it correctly is not enough. Distinguish integrity from retrieval accuracy OWASP's data and model poisoning category includes manipulation of data used in training, fine-tuning, or embedding pipelines. [Its guidance](https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/) discusses the consequences of accepting manipulated inputs. In a business knowledge system, an analogous review follows who can introduce or replace documents that the assistant treats as authoritative. For a controlled test, give a travel assistant an approved reimbursement policy and a second document with a similar title but a different approval threshold. See which one it uses and how it labels the source. An accurate quote from the unapproved document would still give the employee the wrong guidance. Establish which sources carry authority A knowledge inventory can distinguish approved policies, working drafts, discussion threads, and external reference material. Those categories can inform retrieval rules and answer presentation. A draft uploaded yesterday does not automatically supersede an approved policy with an older timestamp. Record document ownership, approval status, version history, and the source location carried through ingestion. If the pipeline strips these attributes, the answering system may have no basis for explaining why one of several conflicting documents was used. Exercise conflict and replacement cases Create a synthetic policy set with one approved document, one draft, and one superseded version. Ask questions whose answers differ between the documents. Inspect both the selected chunks and the citation shown to the user. Then change the draft's title and upload date to test whether superficial relevance displaces the approved source. Repeat the exercise after withdrawing a document. Verify how the index and cached answers respond. A documented delay may be an operational constraint, but it still needs to be visible to whoever owns the policy and the assistant's release decision. Keep the incident response path specific If an unauthorized document enters the corpus, responders need to identify when it was indexed, which revisions were affected, and which answers referenced it. That requires source identifiers and version information rather than only a copy of the final generated text. Restore the approved source, rebuild affected index entries, and invalidate the relevant caches. Then check that queries retrieve the correct version again. Keep the affected document and answer records with the incident; correcting one response may leave other copies in use. Sources [OWASP: RAG Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html). The travel-policy example is a controlled integrity test, not an account of an actual policy change. ### AI Security Evaluations Need Different Questions From Accuracy Tests URL: https://getceron.com/blog/ai-security-evaluations-business-acceptance Author: Mario Luckeneder, Founder of Ceron Published: 2026-10-02T00:00:00-07:00 AI Security Evaluations Need Different Questions From Accuracy Tests An assistant may answer most product questions correctly while mishandling one request involving another customer's account. Averaging these outcomes into a single quality score hides the distinction between an imperfect answer and an authorization failure. Security evaluation asks whether the application respects defined boundaries under specified conditions. Accuracy evaluation asks whether an answer matches the expected information. A release process can use both, with separate acceptance criteria and evidence. Define the prohibited outcome NIST's Generative AI Profile discusses risk management across the AI lifecycle, including measurement and evaluation. It provides a framework for organizing risks rather than a universal passing score for every product. [The NIST profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) supplies that broader context. For an account assistant, define failures such as retrieving another customer’s records, making an unapproved change, or displaying a secret returned by a tool. Decide how to observe each one. Some appear in the answer; others require retrieval or service logs. Build cases around business permissions Use synthetic users with distinct roles and data. Include ordinary authorized tasks, unauthorized requests, ambiguous requests, and external content that attempts to redirect the workflow. The expected result can be a completed task, a request for missing information, or a service-side denial. Keep the permission model fixed while changing the phrasing. This helps distinguish a brittle conversational response from an enforced control. A user asking indirectly for another account's record does not gain access merely because the request resembles a normal support question. Record the complete configuration An evaluation result belongs to a model version, system instructions, tool definitions, permissions, retrieval index, and application build. If any of those change, the result may no longer describe the deployed system. Store enough configuration detail to reproduce the run without putting credentials or customer data into the test package. Also record repeated trials where behavior is variable. One successful refusal is an observation, not an estimate of a universal failure rate. Reporting the number of cases, number of trials, and observed outcomes makes the limits of the evaluation visible. Separate severity from frequency An authorization failure in a rarely exercised case can still require release attention. A high frequency of harmless formatting errors may instead affect usability. The product owner can decide on separate release conditions for these categories rather than allowing a large set of easy questions to dilute a significant security result. For a scoped assessment, the deliverable can list tested boundaries, failed cases, service traces, and retest results. It can also state which tools, languages, document formats, or user roles were excluded. Those exclusions describe remaining coverage, not evidence that the untested areas are safe. At the release meeting, review the tested permissions, failures, and retest results alongside the quality score. Identify the tools and roles the evaluation did not cover so the team knows where evidence is still missing. Sources [OWASP: AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html). The account-assistant evaluation is an illustrative application of lifecycle risk assessment. ### Passkey Rollouts Need an Account Recovery Plan URL: https://getceron.com/blog/passkey-rollout-account-recovery Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-02T00:00:00-07:00 Passkey Rollouts Need an Account Recovery Plan A passkey rollout changes how a user proves control of an account. It also changes what happens when the user replaces a phone, loses a security key, or cannot access a synchronized credential. The normal sign-in flow and the recovery flow form one account lifecycle. Before rollout, check who can register another authenticator and how the help desk verifies someone who has lost theirs. Test those routes as well as the passkey sign-in button. Understand the protection being added NIST describes phishing resistance as a property of an authentication protocol that prevents disclosure of usable authentication secrets to an impostor verifier without relying on the user's vigilance. Cryptographic binding to the intended service is central to that protection. [NIST's authenticator requirements](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/) explain the distinction from manually entered codes. That protection applies to authentication. It does not independently prevent malware on a signed-in device from acting through an existing session, nor does it determine how a help desk verifies a recovery request. These remain separate parts of the system to review. Enrollment establishes future authority Adding an authenticator gives another credential the ability to sign in. An illustrative customer portal might allow enrollment after a fresh authentication, then notify the user through an established channel. The exact requirements depend on the account's assurance needs and the identity system in use. Test enrollment from a normal session, a stale session, and a recently recovered account. Inspect whether a user can list and remove authenticators, and whether security notifications identify the change without exposing credential material. Registration should be treated as an account-security event rather than a cosmetic profile update. Exercise recovery before a real lockout Use a test account to simulate the loss of its primary device. Follow every supported recovery path, including help-desk handling if offered. Record which identity evidence is requested, who can approve recovery, and whether the process removes or preserves existing authenticators and sessions. A fallback can change the effective assurance of the account. For example, if an email link alone permits a new credential to be registered, control of that mailbox becomes relevant to account recovery. That may be a deliberate product decision, but it needs to be documented and evaluated alongside the normal passkey flow. Measure coverage across the lifecycle Enrollment counts show adoption, while recovery success, unauthorized enrollment attempts, and session revocation results describe other operational properties. Keep these measures separate. A high registration rate does not establish that dormant password or recovery paths have been reviewed. Keep the results for sign-in, credential addition, device loss, recovery, and account closure. Use the failed cases to update support training or verification steps before expanding the rollout. Sources [NIST: Authenticator Event Management](https://pages.nist.gov/800-63-4/sp800-63b/events/). The portal workflow is illustrative; applicable assurance requirements depend on the deployment. ### After an Account Reset, Which Sessions Still Work? URL: https://getceron.com/blog/session-revocation-after-account-compromise Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-20T00:00:00-07:00 After an Account Reset, Which Sessions Still Work? Changing a password does not describe every credential already issued to an account. A browser session, mobile application token, and connected service may each have a separate lifecycle. During account recovery or employee departure, the business needs to know when each access path actually stops working. Measure how long revocation takes at each application. The identity provider may mark access as revoked while an application continues accepting a session under its own expiration rules. Map the credentials already in use Microsoft's emergency access-revocation guidance distinguishes the identity provider's token behavior from sessions controlled by applications. It explains why removing identity access may not immediately terminate every application session. [The Microsoft guidance](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access) provides one documented example of this boundary. List the credentials in use: browser sessions, refresh tokens, mobile clients, application-specific passwords, and API keys where supported. Check which ones survive a password change and which need a separate revocation action. Define what revocation means for each service A service may check authorization on every request, accept an access token until expiry, or maintain its own server-side session. These choices affect the delay between an administrative action and the last accepted request. The expected delay should be explicit in an offboarding or incident procedure. Also distinguish removing access from deleting information. Terminating a session does not remove files already downloaded to a managed or unmanaged device. That is a separate data-handling question and should not be presented as a result of credential revocation. Build a controlled revocation timeline Sign a synthetic user into representative applications on two test devices. Record a successful request from each client, perform the approved reset and revocation actions, and repeat harmless read requests at defined intervals. Include token renewal attempts where the application supports them. Record the administrative action time, the last successful request, and the first denial. Test an active connection as well as a newly opened session. A dashboard screenshot saying the user is disabled is evidence of the configuration change; the request results establish what the application enforced. Turn the result into an operational procedure If one application requires a separate session termination call, include it in the procedure and assign an owner. If another has a documented propagation delay, record the delay and any temporary containment available. The procedure can then describe an ordered response rather than assuming one identity action covers all services. Retest when adding a new single sign-on application or changing token lifetime settings. The evidence can support a precise statement such as all tested application sessions were denied within the measured interval. It cannot establish the behavior of untested applications or personal devices outside the review's scope. Sources [NIST: Session Management](https://pages.nist.gov/800-63-4/sp800-63b/session/). The multi-application account and timing exercise are illustrative. ### Password Reset Flows Deserve Their Own Security Review URL: https://getceron.com/blog/password-reset-flow-security-review Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-06T00:00:00-07:00 Password Reset Flows Deserve Their Own Security Review A password reset changes the credential that controls an account. Although the interface often consists of one email and two form fields, the workflow touches identity verification, messaging, token storage, and existing sessions. Each transition can affect who receives access. A security review can follow the entire reset lifecycle, from requesting a link to using the account afterward. Testing only whether a valid link works leaves several important conditions unexamined. The token represents a limited authorization OWASP recommends reset tokens that are unpredictable, bound to a user, appropriately expiring, and invalidated after use. It also describes consistent responses and request controls to limit account enumeration and abuse. [The forgot-password guidance](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) provides the baseline. A portal’s reset token should permit one credential change for one account. Check that a caller cannot select another account by changing a request field. The server should obtain the account from its trusted token record or validated claims. Check how links are created and delivered The application needs a trusted public origin for the reset link. If it constructs that origin from unvalidated request information, the delivery path can be altered. The review can inspect this behavior with a test mailbox and a harmless alternative hostname, without sending any messages to real customers. Email previews, analytics, and support tools can also encounter reset URLs. Review whether tokens appear in routine logs or third-party requests. A credential-bearing link requires different handling from an ordinary navigation URL. Test expiry, reuse, and concurrent attempts Request two reset links for a synthetic account and document the intended behavior of the earlier link. Use one link successfully, then try to reuse it. Test a token after expiry and a token issued for another test account. Each result should be consistent with the documented lifecycle. Where the workflow allows concurrent submissions, verify that a single-use token cannot authorize two separate changes. The relevant evidence is the final credential state and token-consumption record, not just the text displayed by the form. Follow the account after the reset Check whether existing sessions are revoked, whether the user is notified, and whether any connected credentials remain valid. Products can have different session policies, but the behavior should be intentional and described accurately to the user. A message claiming every device was signed out needs supporting verification. Include support overrides and administrator-initiated resets in the report. Record how each route verifies identity and what access it grants afterward. These routes may skip parts of the automated flow, so they need their own tests and audit records. Sources [OWASP: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html). The business portal and test mailbox are illustrative assessment fixtures. ### OAuth Refresh Token Rotation: When Two Workers Renew the Same Grant URL: https://getceron.com/blog/oauth-refresh-token-rotation-business-integrations Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-24T00:00:00-07:00 OAuth Refresh Token Rotation: When Two Workers Renew the Same Grant A scheduled connector can have several workers sharing one customer authorization. When an access token expires, two workers may independently try to renew it. With refresh token rotation, the first successful exchange changes the credential that later requests must use. The resulting failure can look like an intermittent integration outage. Understanding the sequence requires separating a provider's replay protection from the client's coordination of legitimate work. Rotation creates a sequence of credentials RFC 9700 describes rotation as issuing a new refresh token with each exchange and invalidating the previous token while retaining information about their relationship. Reuse of an invalidated token can reveal a possible compromise. For public clients, the standard requires sender-constrained refresh tokens or rotation to detect replay. [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html) explains the security requirements. Auth0 documents one implementation in which detected reuse invalidates the token family, requiring a new authorization grant. [Its rotation documentation](https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation) illustrates why a client cannot treat an old refresh token as an unlimited retry credential. Exact behavior depends on the provider and configuration. Trace one shared grant across workers Suppose two invoice-import workers read credential revision seven. Worker A renews it and stores revision eight. Worker B then submits revision seven. Trace the provider’s response and the worker’s next action to see whether the connector recovers or keeps submitting a retired credential. A client design can give one worker responsibility for renewal and make other workers wait for the resulting credential revision. Coordination must cover every process that shares the grant. A lock held only inside one process does not coordinate independent queue workers or deployment instances. Treat a lost response as an uncertain outcome A network timeout does not establish that the authorization server rejected the exchange. The provider may have rotated the token while the response was lost. Blindly resending the previous token can therefore have a different effect from retrying an ordinary read request. Define recovery using the provider's documented behavior, including any supported overlap interval. Bound retries, distinguish transient transport failures from revoked authorization, and request reconnection when recovery requires user authorization. An undocumented assumption about token reuse should not determine whether customer jobs continue. Test the sequence and its customer impact In a supported test environment, exercise a normal renewal, two concurrent workers, a delayed response, and controlled reuse of a retired test token. Record credential revision numbers, worker identifiers, provider error categories, and resulting job states without recording token values. Check that the owner is notified when the integration stops and that reconnection resumes imports without duplicate records. Document the renewal states and recovery steps, including when the user must authorize the account again. Sources The IETF and Auth0 references above describe the protocol and one provider implementation. The accounting connector and revision numbers are illustrative. ### OIDC for Deployments: Replacing a Stored Secret With a Trust Policy URL: https://getceron.com/blog/oidc-ci-cloud-deployment-credentials Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-11T00:00:00-07:00 OIDC for Deployments: Replacing a Stored Secret With a Trust Policy A deployment pipeline can obtain cloud access without keeping a long-lived cloud key in its secret store. With OpenID Connect, the cloud provider can verify claims about the running job and issue temporary credentials. The access decision moves from possession of a stored secret to a configured trust relationship. That change reduces one credential-management burden while making the trust policy central to deployment security. The provider needs to distinguish the intended release job from other jobs that can request an identity token. Examine what the cloud provider trusts GitHub documents how Actions jobs use OIDC tokens to authenticate to cloud providers. The provider evaluates configured conditions before issuing access. Repository, branch or environment context, workflow identity, and token audience can be relevant to that decision. [GitHub's OIDC documentation](https://docs.github.com/en/actions/concepts/security/openid-connect) explains the exchange. Give staging and production separate cloud roles. Test that a staging job cannot obtain the production role, even when both workflows run in the same repository. Check the role’s resource permissions as well as the trust policy. Short lifetime does not reduce granted permissions A temporary credential can still modify production resources during its valid period. Review the role's allowed operations and resources separately from the credential's duration. A deployment that updates one service may not need account-wide administrative access. Also inspect who can change the workflow that obtains the credential. Repository write permissions, workflow review requirements, and environment approval rules contribute to the effective access path. Protecting the cloud role without examining those upstream changes leaves part of the authority chain unreviewed. Use positive and negative trust tests Confirm that the approved release job can obtain the intended role. Then use controlled jobs with a different branch, environment, or repository context to verify rejection. Test the exact conditions the policy claims to restrict rather than relying on a generic invalid-token case. Retain sanitized claim sets, provider decision records, and the resulting role identity. Do not retain the complete short-lived token in the assessment report. The useful evidence is which condition matched or failed and what authority was issued. Remove obsolete access after migration A successful OIDC deployment does not automatically invalidate the static key it replaced. Inventory prior secrets, downstream copies, and fallback workflows. Revoke obsolete credentials through their issuing service and verify that the release process continues through the intended path. Keep the successful release test and the rejected branch, environment, or repository tests together. List legacy paths that still use stored keys and assign their retirement to an owner. This shows how much of the migration is complete. Sources [GitHub: Security Hardening for GitHub Actions](https://docs.github.com/en/actions/reference/security/secure-use). The staging and production roles are illustrative. ### Service Accounts Need Owners, Expiration Decisions, and Retirement Tests URL: https://getceron.com/blog/service-account-ownership-and-retirement Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-29T00:00:00-07:00 Service Accounts Need Owners, Expiration Decisions, and Retirement Tests An automated process can continue using an account after the employee who created it leaves. The account may belong to a nightly import, an old reporting tool, or a deployment script whose original purpose is no longer documented. Its activity can look routine because it has been running for years. Give each service account a current owner and a documented purpose. That owner needs to know what will break if its credential changes and when the account can be retired. An account name is not an ownership record Microsoft's service-account guidance addresses creation, permissions, ownership, and lifecycle management. It distinguishes automated identities from ordinary user accounts and recommends maintaining the context needed to govern them. [The Microsoft guidance](https://learn.microsoft.com/en-us/entra/architecture/govern-service-accounts) describes this operational approach. For an inventory synchronization job, record the application owner, maintainer, accessed systems, credential location, schedule, and retirement condition. An account named after a former employee does not tell the next administrator who can approve a permission change. Compare granted access with observed work List the operations the process performs and compare them with the account's permissions. A job that reads stock levels may not need to change supplier payment information. Observation helps identify unused access, but a short observation window can miss monthly or annual tasks. Review documented requirements alongside activity records. If the team cannot explain a permission, record that uncertainty and investigate it before making a production change. Removing access without understanding dependencies can interrupt work; leaving it indefinitely without an owner preserves an unreviewed access path. Plan credential changes as application changes Changing a service credential can affect several workers, scheduled jobs, and recovery scripts. Identify all consumers and define how they receive the new credential. Where the platform supports managed identities or temporary credentials, evaluate whether those mechanisms fit the workload instead of assuming every process requires a stored password. In staging, replace the credential and observe the next scheduled cycle. Test the failure path as well: does an authentication error produce an actionable alert, or does the job stop silently while the dashboard continues displaying old data? Retire the identity with evidence A controlled retirement can stop the process, disable its access, and monitor for unexpected attempts before final deletion under the organization's retention policy. Record which business outputs were checked and whether any hidden consumer still depended on the account. Separate accounts confirmed unused from those whose activity is unknown. List missing owners and unexplained permissions, then agree the investigation and retirement order with operations. Keep the business outputs checked during each retirement in the record. Sources [Microsoft: Govern On-Premises Service Accounts](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-govern-on-premises). The synchronization job is illustrative. ### Emergency Administrator Access Must Work During an Identity Outage URL: https://getceron.com/blog/emergency-admin-access-testing Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-17T00:00:00-07:00 Emergency Administrator Access Must Work During an Identity Outage An identity outage can affect the same administrator accounts needed to repair it. A federation problem, device loss, or restrictive policy change may prevent normal access to the management console. Emergency access exists to provide a defined recovery route for such conditions. That route also holds privileged authority. It needs an operating procedure, controlled custody, and evidence that it works under the failure conditions it is intended to address. Identify shared dependencies Microsoft's emergency-access guidance discusses administrative accounts that can be used when normal access is unavailable. It recommends avoiding dependence on the same authentication method used for ordinary administration and monitoring emergency account use. [The Microsoft documentation](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) gives platform-specific configuration guidance. Suppose the organization keeps its recovery procedure and credentials in a vault that requires the normal identity provider. If that provider fails, the team loses both console access and its recovery instructions. Include the vault, devices, documentation, and authorized people when checking outage dependencies. Define custody and permitted use Record who can obtain the emergency credential or hardware authenticator, under which conditions, and how access is recorded. Separate routine administration from the exceptional recovery procedure so that emergency use remains identifiable in operational records. The procedure can specify a second-person check or other oversight appropriate to the organization. The technical implementation must still allow the intended recovery during an outage. A control that depends on an unavailable approver or system needs an explicit alternative rather than an undocumented workaround. Test without causing the outage A planned drill can verify credential availability, account sign-in, required administrative functions, and alert delivery without disabling the primary identity system. Use the provider's supported testing methods and keep the scope to agreed, reversible actions. Measure whether the on-call team can locate the procedure and complete the authorized task. Check that the monitoring recipient can receive the alert if the primary corporate login is unavailable. An alert sent exclusively to a mailbox behind the failed identity path may not reach the people expected to respond. Close the loop after use Record the reason for access, actions performed, changes made, and resulting system state. Review credential custody and replace exposed or compromised material as required. A successful drill should leave the environment in its intended configuration, with any test changes accounted for. Record the last successful drill, anything that prevented recovery, and any privileges beyond the agreed emergency task. An emergency account on an inventory is useful only if the on-call team can reach it and use it under the intended failure conditions. Sources [NIST: Authenticator Event Management](https://pages.nist.gov/800-63-4/sp800-63b/events/). The outage and vault example are illustrative. ### SCIM Offboarding: Verify the Access Change Behind the Directory Update URL: https://getceron.com/blog/scim-offboarding-access-verification Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-02T00:00:00-07:00 SCIM Offboarding: Verify the Access Change Behind the Directory Update Automated provisioning can create a SaaS account and assign its groups when an employee joins. The reverse process is more complex than removing a name from a directory. The application may hold its own sessions, API credentials, shared objects, and scheduled tasks. Verify offboarding inside each destination application. A processed provisioning event may disable new sign-ins while leaving existing sessions, API tokens, or scheduled jobs active. SCIM manages identity resources SCIM defines an HTTP protocol for creating, retrieving, modifying, and deleting identity resources such as users and groups. Its protocol operations do not automatically specify the full business lifecycle of every SaaS feature. [RFC 7644](https://www.rfc-editor.org/rfc/rfc7644.html) defines the protocol, while the core schema describes attributes such as a user's administrative status. An illustrative design platform may disable a user through provisioning while retaining projects for the rest of the company. Keeping those projects can be intentional. Whether the former user can still access them through an existing session is a separate behavior to verify. Establish the application's deactivation semantics Document what deactivation does to sign-in, active sessions, personal API tokens, group membership, ownership, and external sharing. Some items may require a separate administration action. The application's integration documentation and actual configuration determine the expected result. Also review how reactivation behaves. If a person returns or a provisioning mistake is corrected, the application may restore previous roles. The business needs to know whether that restoration matches the current access decision or silently reintroduces permissions from an earlier job. Test the full transition with a synthetic user Create a test user through the normal provisioning path, assign representative roles, and establish an active session. If the product supports them, create a harmless API token and scheduled job. Remove the user's access through the identity provider and record the resulting events at both ends. Attempt ordinary reads and permitted test actions afterward. Measure the delay until denial and inspect whether scheduled work still runs. Reconcile differences between the directory state and application state rather than treating either administrative screen as the complete record. Make failures visible to an owner A provisioning connector can fail because of a revoked credential, changed mapping, or unavailable destination. Determine where such failures appear and who acts on them. A departure process that completes in the HR system while deactivation fails downstream requires an exception route. Keep a record for each application showing the expected deactivation actions, observed delay, manual steps, and owners. Use it when closing an employee’s departure and repeat the checks after adding a SaaS product or changing provisioning mappings. Sources [IETF: SCIM Core Schema, RFC 7643](https://www.rfc-editor.org/rfc/rfc7643.html). The design platform is illustrative, and deactivation effects depend on the application. ### SSO Domain Claims: Proving Which Company Controls a Workspace URL: https://getceron.com/blog/sso-domain-claims-tenant-onboarding Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-01T00:00:00-07:00 SSO Domain Claims: Proving Which Company Controls a Workspace Enterprise single sign-on often begins with a domain. A product may route employees from a company email address to a particular identity provider or let an administrator claim that domain for a workspace. Those conveniences depend on an ownership decision that must be made carefully. An email suffix does not prove that a workspace administrator controls the company’s domain. Verify that control before letting the administrator change how everyone at that domain signs in. Separate domain proof from account identity An identity assertion needs to be validated for the expected issuer, recipient, and application context. OWASP's SAML guidance explains these validation boundaries and the consequences of accepting an assertion in the wrong context. [The SAML security guidance](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) supplies the protocol background. Domain verification is a separate product workflow. An illustrative SaaS service might require a DNS challenge before allowing an administrator to claim a company's domain. That proof demonstrates control of the configured DNS location at a point in time. The product still needs rules for conflicting claims, subsidiaries, and later ownership changes. Account linking can alter existing access When SSO is enabled, existing accounts may already use the same email addresses. Decide whether they are linked automatically, require confirmation, or remain separate. The authenticated issuer and stable subject identifier matter because email addresses can change and may be reassigned. Record how the application selects the tenant before and after authentication. User-supplied workspace identifiers can be selectors, but the resulting assertion and account membership must still authorize access to the chosen workspace. A valid login to one company must not establish membership in another. Test competing and changing claims Use domains controlled for testing to exercise a normal claim, a second workspace claiming the same domain, and a failed challenge. Verify that an unverified workspace cannot alter the sign-in path for existing users. Include removal and re-verification of a previously claimed test domain. Then test an assertion from a different configured test issuer and an existing user whose email changes. Inspect the resulting account identity and workspace membership. The objective is to establish whether linking follows the documented ownership model rather than a loose match on visible email text. Document the transition procedure Domain transfers, acquisitions, and identity-provider replacements can require coordinated changes. A procedure can identify the current workspace owner, verification evidence, affected users, and rollback conditions. Audit records should show who changed the identity configuration and what changed. Use test domains to verify onboarding and transfer behavior. In the report, distinguish invalid identity assertions from mistakes in domain ownership or account linking. Both can grant the wrong access, but the fixes belong in different parts of the application. Sources [OWASP: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html). The DNS verification design is illustrative and is not a universal SSO protocol requirement. ### Vendor Access Reviews Need More Than an MFA Checkbox URL: https://getceron.com/blog/vendor-access-phishing-resistant-mfa Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-20T00:00:00-07:00 Vendor Access Reviews Need More Than an MFA Checkbox A company can require multifactor authentication for employees while allowing an external administrator to use a different access path. That administrator may enter through a vendor portal, a shared support account, or a remote-management service. The effective authentication boundary includes all of these routes. An access review can identify the method actually used for each privileged route, the permissions it grants, and what happens when the normal authentication method is unavailable. MFA methods have different properties CISA's phishing-resistant MFA guidance explains why FIDO/WebAuthn-based authentication provides protection against credential phishing that manually entered codes do not provide in the same way. Number matching can improve some push-based workflows, but it is not equivalent to phishing-resistant authentication. [CISA's implementation guidance](https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) describes these distinctions. An assurance statement that says MFA enabled leaves the method unspecified. For a vendor with administrative access, the review can request the enforced method, enrollment process, fallback routes, and scope of enforcement for the particular service being accessed. Review the access path the vendor uses A support provider may sign in to its own management platform and open a customer session from there. The customer might never see that first authentication event. Ask for configuration records, session logs, or a supervised demonstration showing the method enforced on that route. These forms of evidence have different limits. A policy document describes a requirement; a configuration record describes a setting; a controlled access attempt describes observed enforcement. Record which evidence supports each conclusion instead of treating the documents as interchangeable. Include fallback and shared accounts Inspect emergency access, lost-device recovery, and any accounts excluded from the normal policy. A vendor's named-user accounts may be well controlled while a shared technical account remains available through another interface. Identify the business reason and owner for each exception. Permissions also matter after authentication. A support task might require access to one application for a limited period. Broad, persistent administrator access increases the operations available to the session regardless of how the person authenticated. Verify removal and accountability In a controlled exercise, grant a test vendor identity the agreed role, confirm its permitted task, and remove access. Check active sessions and separate remote-access tools. Record the individual or service identity associated with each action so the customer can distinguish vendor activity from internal administration. Record each vendor route’s authentication method, privileges, expiration, fallback, logging, and removal result. Identify any conclusion that still needs evidence from the provider before accepting the access arrangement. Sources [NIST: Phishing Resistance](https://www.nist.gov/blogs/cybersecurity-insights/phishing-resistance-protecting-keys-your-kingdom). The support-provider scenario is illustrative. ### GitHub Actions: The Trust Boundary Between a Pull Request and a Release URL: https://getceron.com/blog/github-actions-pull-request-trust-boundaries Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-09T00:00:00-07:00 GitHub Actions: The Trust Boundary Between a Pull Request and a Release A pull request is proposed code. A release workflow may hold permission to publish packages or deploy a service. When these two contexts meet, the pipeline has to preserve the distinction between a contribution awaiting review and code authorized to run with release privileges. The relevant security question is which inputs a privileged job executes or trusts. That includes source files, build scripts, generated artifacts, and configuration supplied by earlier jobs. The event determines an initial trust context GitHub documents the security implications of pull_request_target, which uses the base repository's workflow context. Risk arises when that privileged context checks out and executes code from an untrusted pull request. The checkout alone is not the execution; a later build, test, or script invocation completes that path. [GitHub's dedicated guidance](https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target) explains the distinction. A documentation repository might use one job to label contributions and another to publish the site. The labeling job has no reason to run the contributor’s build scripts. Review its permissions separately from the publishing job. Follow artifacts as well as source checkout A privileged job can consume an artifact produced by a less-trusted workflow. If it executes a script from that artifact or treats its contents as trusted deployment instructions, the boundary can be crossed without a direct source checkout in the release job. Record where each artifact originated, which commit it represents, and how the consumer verifies that context. A filename or successful upstream status does not alone establish that the artifact came from an approved release revision. Review permissions at the job level Inspect repository-token permissions, environment secrets, deployment approvals, and network access. A test job may need to read source and upload results while a publishing job needs a narrower set of write operations. The review can identify permissions that are inherited broadly but used by only one task. Also examine expressions that place issue titles, branch names, or other contributor-controlled text into scripts. The source of a string matters when a shell or interpreter processes it. Treating such values as data avoids confusing workflow metadata with executable instructions. Validate with harmless fixtures Use a controlled fork or test repository to submit a contribution that creates a harmless marker during its build. Confirm where the marker executes and whether that context has sensitive authority, without exposing or printing secrets. Test artifact acceptance using deliberately mismatched revisions. Keep a trace from the triggering event through the job’s inputs and permissions to the release output. Repeat the tests after changing triggers, reusable workflows, runners, or artifact handling. Those changes can give contribution code access it did not have in the reviewed setup. Sources [GitHub Security Lab: Preventing Pwn Requests](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/). The documentation repository and marker are illustrative test fixtures. ### Artifact Attestations: What Build Provenance Can Prove URL: https://getceron.com/blog/artifact-attestations-what-provenance-proves Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-26T00:00:00-07:00 Artifact Attestations: What Build Provenance Can Prove A downloaded binary can arrive with a signed statement describing where and how it was built. That statement adds evidence about the artifact's origin. Its value depends on checking both the signature and whether the stated origin matches the organization's release policy. Provenance answers a different question from vulnerability testing. A build can come from the expected repository and still contain a software defect or an unsafe change. Bind the statement to the actual artifact GitHub's artifact-attestation documentation describes signed provenance associated with build outputs. Verification connects an artifact digest to information about its build context. [GitHub's attestation guidance](https://docs.github.com/en/actions/concepts/security/artifact-attestations) explains the intended use. When a release service downloads an archive and its attestation, verify that their digests match. An attestation for a different archive tells you nothing about the file being deployed, even if both files have the same name. A trusted signature needs an acceptance policy The verifier can check whether the signer, source repository, build workflow, and other relevant claims match approved values. A valid statement from an unrelated project remains unrelated. The organization has to define which build identities and source contexts are authorized for its application. This decision can be expressed in the deployment process rather than left to an operator reading a badge. Record what happens if the attestation is missing, invalid, or valid but outside the allowed policy. Silent fallback to an unverified artifact changes the assurance provided by the control. Keep provenance and review separate An attestation does not establish that reviewers approved the code or that tests exercised every relevant behavior unless those claims are specifically made and verified through the chosen system. Even then, completion of a review or test does not prove absence of defects. For business acceptance, distinguish three records: the artifact that will run, evidence of its approved build path, and evidence of testing or review. Linking them by revision and digest allows a release reviewer to see whether they describe the same deliverable. Test rejection paths before relying on them Use a harmless test artifact to verify normal acceptance. Then change the file after attestation, supply evidence from another repository, and omit the evidence entirely. Each case tests a different rule. Record the deployment decision and whether any bypass path was used. Check where verification runs and whether rollback and emergency jobs enforce it too. Record any path that accepts an unverified archive. A signed normal release does not protect an alternate deployment route that skips the check. Sources [SLSA: Verifying Artifacts](https://slsa.dev/spec/v1.2/verifying-artifacts). The release service is an illustrative verifier design. ### npm Trusted Publishing Changes How a Release Gets Permission URL: https://getceron.com/blog/npm-trusted-publishing-release-controls Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-14T00:00:00-07:00 npm Trusted Publishing Changes How a Release Gets Permission Publishing a package gives downstream users new code to install. A stored publishing token traditionally authorizes that operation. npm trusted publishing can instead establish a relationship with a supported CI provider, allowing a particular workflow identity to publish through an OIDC exchange. This changes the credential path. It does not remove the need to control who can change the release workflow or what package contents that workflow produces. Review the configured publisher identity npm documents trusted publishing as an OIDC trust relationship between the registry and the CI provider. Supported provider behavior and configuration requirements are described in its maintained documentation. [The npm trusted-publishing guide](https://docs.npmjs.com/trusted-publishers/) is the authoritative reference for those requirements. Match the package’s configured repository and workflow to the actual release job. Record the exact identity conditions and who can change them in the repository and registry. Two workflows with similar names may have different publishing rights. Package ownership remains an access decision A release workflow operates within the registry's package and organization permissions. Review package maintainers, organization roles, and administrative recovery alongside the automated publisher. An alternate maintainer credential may still publish even if the main workflow has been restricted. The migration inventory can distinguish active publishing paths, emergency procedures, and obsolete tokens. Removing a token from CI does not revoke a copy stored elsewhere. Revocation has to occur at the issuing service, followed by verification that the intended workflow still functions. Inspect what the workflow packages The published archive may include generated JavaScript, declarations, configuration, or other files that differ from the visible source tree. Record how the package is assembled and inspect its contents before release. Provenance can link a package to a build context without establishing that every included file was intended. Use a test package or non-production release process to compare the packed file list with the approved distribution scope. Check that local environment files, development credentials, and unrelated build artifacts are excluded. This is a content check distinct from publisher authentication. Verify unauthorized contexts are rejected Test the approved workflow and controlled variants that do not match the publisher configuration. The expected result is that only the configured context receives publishing authority. Use a dedicated package so these tests do not create unintended public releases of a production dependency. Report the tested publishing identity, inspected package contents, other maintainer access, and old-token retirement results. Keep these findings separate from vulnerability testing and from checks a downstream consumer may perform. Sources [npm: Viewing Package Provenance](https://docs.npmjs.com/viewing-package-provenance/). The tooling package and test release are illustrative. ### SBOM and VEX: Two Different Records in a Vulnerability Investigation URL: https://getceron.com/blog/sbom-vex-vulnerability-response Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-31T00:00:00-07:00 SBOM and VEX: Two Different Records in a Vulnerability Investigation A software bill of materials can identify a component inside a product. It does not automatically establish whether a newly disclosed vulnerability is exploitable in that product's configuration. A Vulnerability Exploitability eXchange statement, or VEX, addresses the product's relationship to a particular vulnerability. These records are complementary. One describes composition; the other communicates an assessment. A business consuming them needs to know which release they describe and what evidence supports the assessment. Match the inventory to the shipped release OWASP's SBOM guidance distinguishes an inventory from the dependency relationships that help explain how components enter a build. It also notes that absent entries do not prove a component is absent from the software. [The dependency graph and SBOM guidance](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) describes release binding and completeness limits. Suppose a supplier ships appliance version 4.2 but supplies an inventory for version 4.1. Check the product identifier, version, artifact hash, and generation scope before using that inventory to assess the installed appliance. Read the VEX justification A not-affected statement requires more than a status label. The issuer's identity, product version, vulnerability identifier, and stated justification determine how the claim can be evaluated. A component may be present while a vulnerable feature is absent or unreachable under specified conditions. The customer's configuration can matter. If the statement assumes a feature is disabled and the customer enables it, the original justification may no longer apply. Keep the supplier statement and the local configuration evidence connected instead of copying the status into a permanent exception. Work through a release-specific example Suppose a synthetic product inventory lists a library affected by an advisory. The supplier states that the vulnerable parser is not included in the shipped build. The reviewer can request the exact build scope and supporting analysis, then compare that claim with the deployed artifact and enabled functionality. If the evidence is incomplete, the result is an unresolved applicability question. It is not proof of exploitation, and it is not proof that the product is unaffected. That distinction supports a measured response while further evidence is collected. Preserve the decision history Record the inventory used, supplier statement, local checks, decision owner, and review date. Reassess when the product changes, the advisory is updated, or the assumptions supporting the statement no longer hold. Retain earlier records so an incident review can reconstruct what was known at the time. Trace a component from the inventory to the deployed release and the vulnerability decision. Check that the team can obtain the evidence behind a supplier’s VEX status and reconsider it when local configuration changes. Sources [CycloneDX: Vulnerability Exploitability Exchange](https://cyclonedx.org/capabilities/vex/). The appliance and parser example are illustrative. ### A Leaked Secret Requires Revocation, Not Just a Deleted Commit URL: https://getceron.com/blog/leaked-secret-remediation-beyond-git-deletion Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-18T00:00:00-07:00 A Leaked Secret Requires Revocation, Not Just a Deleted Commit Deleting a credential from the latest source file changes what future readers see at that location. It does not invalidate the credential, remove existing clones, or establish whether the credential was already used. Containment begins with the authority granted by the disclosed secret. The response needs to identify the issuing service, the credential's permissions, and the applications that depend on it. That information determines how to revoke or replace it while preserving the required business function. Separate credential validity from repository visibility GitHub's guidance on removing sensitive data advises revoking or rotating exposed secrets before undertaking repository-history cleanup. History rewriting has coordination and retention limits because copies may exist elsewhere. [GitHub's sensitive-data removal guidance](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository) explains those considerations. Suppose a deployment token is committed to a private repository and later copied into a public issue. Remove it from the issue, but also revoke it at the issuing platform. Anyone who copied it can otherwise keep using its permissions. Inventory dependent consumers The same secret may be used by production jobs, staging, a developer script, and a recovery procedure. Record these consumers before replacement where circumstances permit. If urgent revocation interrupts a process, the incident owner needs to understand which business operation may stop. Issue replacement credentials with the permissions required by each consumer rather than automatically reproducing broad access. Separate credentials can also improve attribution and allow later revocation of one integration without affecting unrelated work. Look for use during the exposure window Review the issuing service's authentication and action records for the relevant period. Establish the earliest known exposure, revocation time, permitted resources, and available log coverage. Unrecognized use requires investigation; the absence of a matching log entry only supports conclusions within the logging that was actually enabled and retained. Avoid reproducing the secret in tickets, screenshots, or chat messages. A fingerprint, credential identifier, and sanitized evidence can connect the investigation records without creating more usable copies. Verify the old path fails and the new path works Use the provider's supported validation method to confirm that the revoked credential no longer authenticates. Verify each approved consumer with its replacement, then remove stale references from secret stores and deployment configuration. Test the business output, such as a completed backup or successful deployment, rather than only a credential update screen. Handle repository cleanup, scanner suppressions, and prevention controls after containment. In the incident record, keep the exposed permissions, observed use, revocation result, restored consumers, and log gaps. Deleting the source text cannot erase copies already made. Sources [OWASP: Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html). The deployment token example is illustrative. ### Dependency Lockfiles Make Changes Reviewable, but They Still Need Review URL: https://getceron.com/blog/dependency-lockfiles-security-review Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-06T00:00:00-07:00 Dependency Lockfiles Make Changes Reviewable, but They Still Need Review A package manifest can allow a range of dependency versions. A lockfile records a particular resolved dependency tree. That record helps a team explain why a build used one package version rather than another, including packages introduced indirectly by other dependencies. For security review, the lockfile is evidence about selection. It is not an independent assessment of the selected code, its maintainer, or the scripts that may run during installation. Understand the install command's behavior npm documents that npm ci installs from an existing lockfile and fails when the dependency manifest and lockfile disagree, rather than updating the lockfile to reconcile them. It also removes an existing node_modules directory before installing. [The npm ci documentation](https://docs.npmjs.com/cli/v11/commands/npm-ci/) describes these operational differences. A clean release install should use the dependency state from the reviewed revision. Check alternate release jobs too. A job that resolves fresh versions during deployment may produce different dependencies from the normal pipeline. Review the dependency change as a graph A direct dependency update can introduce or replace transitive packages. The relevant review includes those changes, their source registries, and any new installation behavior. A small manifest edit can produce a larger effective software change. Review tools can summarize changed package names and versions, but the team still needs an acceptance process. Distinguish routine patch updates, packages with new install scripts, registry changes, and dependencies that become part of the production runtime. These categories can require different evidence without treating every update as equally risky. Integrity checks have a defined scope A recorded digest can help detect that downloaded package bytes differ from the expected artifact. It does not establish that the expected artifact was safe in the first place. Similarly, a vulnerability scan only reports what its data and analysis can identify at that time. The build environment remains relevant. Toolchain versions, operating-system packages, platform-specific dependencies, and external downloads can affect the output even when the application lockfile is unchanged. Record these inputs when reproducibility is part of the release requirement. Exercise a dependency update before release In a controlled branch, update a representative dependency and inspect the lockfile diff, package contents, installation output, and application tests. Confirm that CI rejects a deliberately mismatched manifest and lockfile. Check whether developers and release jobs use compatible package-manager settings. Keep the lockfile revision with the application revision and test results. When an advisory arrives, use that record to identify affected deployments. Verify that the release actually used the lockfile before relying on it for that lookup. Sources [OWASP: Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html). The release pipeline is illustrative. ### Pinned Container Images Need a Deliberate Update Process URL: https://getceron.com/blog/container-image-digests-patching Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-25T00:00:00-07:00 Pinned Container Images Need a Deliberate Update Process A container tag is a name that can point to different image content over time. A digest identifies specific content. Pinning a digest makes the selected base image explicit, but it also means a rebuilt application will keep using that image until the reference is changed. Reproducible selection and timely patching are separate requirements. A deployment process needs to satisfy both by recording what it uses and providing a reviewed path for replacing it. Know which image the build selected Docker's build guidance explains that tags are mutable and that digest pinning fixes the image content used by a build. It also discusses the need to update pinned references when adopting newer base images. [Docker's build practices](https://docs.docker.com/build/building/best-practices/) describe this tradeoff. A web service may need a base operating-system patch even when its application source has not changed. Rebuilding with the old pinned digest keeps the old package. Check the replacement image’s contents and digest as part of the patch. Follow the patch through each artifact Record the old base digest, replacement base digest, resulting application-image digest, and deployment revision. Check the final image's contents rather than assuming the updated base remains unchanged through later build steps. Additional package installation can reintroduce versions or add components outside the base image. The running fleet also matters. A registry containing a patched image does not establish that every workload has pulled and started it. Long-running workers, regional deployments, and rollback configurations can retain older images after the main service has been updated. Treat rebuilding as a tested change Run the application's relevant checks against the rebuilt image. Changes to system libraries, certificate stores, or language runtimes can affect behavior even when application source is identical. Include a deployment health check and the business function associated with the service. If the update fails, record the rollback decision and the remaining exposure rather than silently marking the vulnerability resolved. The remediation state should follow the deployed artifact, not the existence of a successful build job. Verify the running digest An assessment can select a sample service and trace its declared image to the actual running digest. Compare that digest with the reviewed release and component inventory. Repeat after a rollout and a controlled rollback to identify which evidence remains available for both states. Record the replacement image, updated workloads, passed checks, and older instances still running. Use that list to track the rollout and plan follow-up work. Pinning a digest makes the chosen image explicit; it still needs an owner who updates it. Sources [Kubernetes: Images](https://kubernetes.io/docs/concepts/containers/images/). The web-service update is illustrative, and rollout behavior depends on the deployment platform. ### Self-Hosted CI Runners Extend the Build’s Access Into Your Network URL: https://getceron.com/blog/self-hosted-ci-runner-isolation Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-27T00:00:00-07:00 Self-Hosted CI Runners Extend the Build’s Access Into Your Network A self-hosted runner executes workflow instructions on infrastructure the organization manages. That machine may reach private repositories, package mirrors, internal services, and cloud endpoints. A job's effective authority includes those connections as well as the permissions visible in the workflow file. This makes runner placement part of the security design. The question is what a job can reach and what state it can leave for the next job. Persistent hosts can carry state between jobs GitHub's security guidance warns that self-hosted runners can be persistently compromised by untrusted workflow code and are not inherently clean environments between jobs. It describes isolation considerations for organizations operating them. [GitHub's secure-use reference](https://docs.github.com/en/actions/reference/security/secure-use) covers these risks. If a test runner and release runner share a host, check writable directories and host credentials as well as their workflow tokens. A test job may be able to alter files the release job later uses, despite having a more restrictive token. Map network and host authority Identify reachable internal services, metadata endpoints, mounted sockets, shared caches, and credentials available to the runner process. A containerized job is not automatically isolated from the host if privileged mounts or runtime controls expose host authority. Separate job classes by the trust level of their inputs and the resources they need. A public contribution test and a production deployment have different requirements. Document which runner groups can accept each job and who can change those assignments. Test cleanup with harmless persistent markers In a dedicated environment, have one job create a benign marker in each agreed writable location. Run a subsequent job and check which markers remain accessible. The test can reveal persistent workspace, cache, or home-directory state without introducing malicious software. Also test whether the less-trusted job can reach a controlled internal endpoint that should be unavailable. Record the network decision and runner identity. A host's network location can grant access even when a job has no explicit application credential. Plan replacement and evidence retention Ephemeral runners can reduce cross-job persistence when the underlying compute environment is actually discarded. Removing a runner's registration alone does not prove that the host, disk, or cached credentials were destroyed. Verify the lifecycle implemented by the infrastructure platform. Preserve job and infrastructure logs outside the disposable environment so an investigation does not lose its evidence when the runner terminates. Record who can modify those logs and how they connect to the workflow revision. Document which jobs share hosts, what each can reach, and what is removed between jobs. Use the marker and network tests to decide which job classes need separate runners. Sources [GitHub: Self-Hosted Runners](https://docs.github.com/en/actions/concepts/runners/self-hosted-runners). The shared-host example is illustrative. ### Private Package Names Need Explicit Registry Rules URL: https://getceron.com/blog/private-package-registry-dependency-confusion Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-10T00:00:00-07:00 Private Package Names Need Explicit Registry Rules A build can use packages from both a public registry and an internal registry. The package manager's resolution rules determine which source supplies each name. If those rules are ambiguous, an internal dependency may be resolved from a location the organization did not intend. The review starts with the actual installation configuration used by developers, CI, and release jobs. A rule present on one engineer's laptop does not establish the behavior of every build environment. Scope and registry are separate properties npm supports associating a package scope with a registry through its configuration. Authentication entries also need appropriate registry scoping so credentials are sent to the intended service. [npm's configuration documentation](https://docs.npmjs.com/cli/v11/configuring-npm/npmrc/) explains these mechanisms. For internal libraries under a company scope, inspect the effective CI registry setting and the resolved lockfile URLs. Confirm that both point to the company registry in a clean install. Check behavior when the private source is unavailable An installation failure can be safer and more explainable than silently obtaining a similarly named package from another source. The intended behavior needs to be explicit. Caching may obscure the result because an install can succeed without contacting the registry at all. Use a clean, isolated test environment to exercise a missing internal package and an unavailable internal registry. Observe the requested destinations and failure result. Do not publish lookalike packages to public registries as a test; controlled local registries can reproduce the resolution question without affecting other users. Review configuration precedence Package managers can read project, user, environment, and command-line settings. The effective value may differ from the file a reviewer first opens. Record which settings are present in the release environment and how secrets are injected without including their values in the report. Also inspect direct archive URLs and Git dependencies, which may bypass ordinary registry selection. A policy covering scoped registry packages does not automatically cover every source type allowed by the manifest. Connect resolution to the released artifact Retain the reviewed dependency state and verify that release jobs use it. Compare a representative developer install with CI, then account for intended differences. This can identify cases where an internal package works locally because of a personal registry setting that is missing in automation. Use the observed destinations and failure results to correct scope routing or remove unintended fallbacks. Then review publisher permissions, package contents, and registry credentials separately. Resolving from the approved registry does not establish that a package is safe. Sources [OWASP: NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html). The company scope and registry-failure tests are illustrative. ### Browser Extensions Belong in the SaaS Access Inventory URL: https://getceron.com/blog/browser-extension-access-business-applications Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-27T00:00:00-07:00 Browser Extensions Belong in the SaaS Access Inventory A browser extension can operate inside the same browser that employees use for customer records, invoices, and administration. Depending on its permissions, it may read page content, inject scripts, or interact with browsing activity. The extension can therefore become part of a business application's data path without appearing in that application's integration settings. Include browser extensions in the access inventory alongside SaaS integrations. Their permissions can let them read business pages even when the application has no record of a connected tool. Permissions describe capabilities, not observed behavior Chrome documents the permissions available to extensions and the warnings associated with them. Host permissions and API permissions have different effects, and some capabilities depend on their combination. [Chrome's permission reference](https://developer.chrome.com/docs/extensions/reference/permissions-list) describes the platform's controls. An illustrative sales extension reads selected CRM pages to format notes. Access limited to that CRM has a different scope from permission to read and change content across all visited sites. Neither permission set, by itself, establishes whether the extension actually transmits customer information; that requires further evidence. Record the publisher and business purpose Inventory the extension identifier, publisher, installed version, requested permissions, deployment method, and responsible business owner. Identify whether installation is centrally managed or left to individual users. A product name alone may not distinguish similarly named extensions. Review how updates are delivered and how permission changes are handled by the browser and organizational policy. The team needs a way to connect a changed capability or publisher relationship to the affected employee population. Use a synthetic business session for review Create a browser profile with test accounts and synthetic records. Exercise the extension's intended feature, then inspect the documented and observed data flow using approved tools. Keep real customer sessions and credentials outside the test environment. Compare the requested access with the function the business approved. If the extension needs broader access for a documented reason, record that reason and the accepted scope. If the scope cannot be explained, the review has identified a question requiring resolution rather than proof of malicious behavior. Verify removal and incident visibility Test whether an administrator can identify affected installations and remove or disable the extension through the supported management process. Record which devices are outside management and what evidence is available about prior versions or use. Removing an extension prevents its future browser execution in the managed context, but it does not recover information already transmitted. Incident response therefore needs both endpoint action and a review of the extension's accessible data during the relevant period. Add each extension’s purpose, permissions, owner, and removal procedure to the access inventory. Keep its installed identifier and version so the team can find affected devices when a publisher or permission changes. Sources [OWASP: Browser Extension Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html). The sales extension is illustrative. ### Presigned Download URLs Carry Access Beyond the Login Screen URL: https://getceron.com/blog/presigned-download-urls-access-control Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-06T00:00:00-07:00 Presigned Download URLs Carry Access Beyond the Login Screen A private document can be delivered through a link that grants temporary access to cloud storage. Once issued, that link may work without returning to the application's login page. The application has exchanged an authenticated access decision for a credential embedded in a URL. Treat the signed link as a temporary credential. Check how long it works, where it is copied, and whether it stays usable after the customer loses portal access. Understand the authority in the URL AWS describes S3 presigned URLs as bearer tokens whose use is limited by the permissions of the signer and applicable expiration and policy conditions. A link can remain reusable during its valid period. Temporary credentials can cause it to expire earlier than the requested URL lifetime. [AWS's presigned URL documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) explains these details. An illustrative invoice portal authorizes a customer, then returns a signed download link. If that link is copied into a support ticket, anyone who can read the ticket may be able to use it while valid. The portal's account permissions do not automatically follow the copied URL. Check issuance before checking expiration The application must verify that the requester may access the selected file before creating the URL. A storage signature can be technically valid even when the application signed the wrong customer's object. Tenant binding and object authorization therefore remain central. Record the object, operation, signer identity, configured lifetime, and any policy restrictions. Avoid treating long, difficult-to-guess URLs as a substitute for authorization. Unpredictability can make discovery harder without correcting an issuance error. Test the document lifecycle Use two synthetic customer accounts and harmless files. Verify that each account can obtain links only for its own permitted objects. Open an issued link in a separate browser context, then test it after the expected expiration. The separate context establishes whether possession alone is sufficient under the selected configuration. Next, revoke the user's application access and check the already issued link. Its continued validity may follow the storage service's design. If the business needs immediate revocation for a particular document class, that requirement must influence the delivery architecture and invalidation mechanism. Inspect where links are retained Application logs, analytics, browser history, messages, and exported reports can retain signed URLs. Review these destinations as potential credential stores and redact signature-bearing query strings where they are not needed. Use non-secret object and request identifiers for ordinary diagnostics. Record who could obtain each link, when it expired, and whether it survived account revocation. Use those results to choose lifetimes and sharing rules for invoices, exports, and other document types. Sources [AWS: Additional Presigned URL Guardrails](https://docs.aws.amazon.com/prescriptive-guidance/latest/presigned-url-best-practices/additional-guardrails.html). The invoice portal is illustrative. ### A Completed Backup Is the Start of a Recovery Test URL: https://getceron.com/blog/cloud-backup-restore-testing-business-recovery Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-23T00:00:00-07:00 A Completed Backup Is the Start of a Recovery Test A backup dashboard can show that a copy was created successfully. Recovery asks whether that copy can be restored into a usable service with the required data, keys, configuration, and access. These are related but different results. Choose a business task as the recovery test. A restored database is not enough if the application still cannot retrieve invoice files, sign users in, or contact a required integration. Define the recovery objective in operational terms AWS Backup documents restore testing as a way to evaluate recovery points and validate restorability through a managed process. Its guidance distinguishes restoration from additional validation of the restored resource. [The AWS restore-testing documentation](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html) explains the service's role. An illustrative order platform needs its database, invoice files, and application configuration to resume customer service. Define which point in time is required, how much data loss is acceptable, and which transaction must work before the service is considered recovered. Those are business requirements that a storage job's success status cannot supply. Include credentials and encryption dependencies Restoration may depend on keys, roles, account access, network configuration, and available capacity. Record who can use those dependencies during an incident and whether the same failure that affected production could prevent access to the backups. Also review deletion and modification authority over recovery copies. Separation of backup permissions can limit the consequences of a compromised application account, but the implemented configuration and recovery procedure need verification. A product label alone does not establish isolation. Restore into a controlled environment Select a recovery point and restore it into an isolated test environment using the documented process. Avoid allowing the restored application to send customer messages, charge payments, or overwrite production integrations. Use test destinations and explicitly controlled network access. Measure the time needed to obtain access, provision resources, restore data, start the application, and complete the agreed business transaction. Compare record counts and selected consistency checks with the expected recovery point. A service that starts successfully may still be missing attachments or relationships between records. Record what the test did not cover One restore does not establish that every recovery point, region, or service can be recovered. Document the selected sample, dependencies, elapsed time, and unresolved gaps. Include any manual step that relied on knowledge not present in the procedure. Record whether the selected data was restored, the agreed transaction completed, and the recovery time met the target. Repeat the exercise after changes to encryption, identity, data structure, or hosting. Successful backup jobs may continue even when one of those changes breaks restoration. Sources [CISA: StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide). The order platform and recovery exercise are illustrative. ### Kubernetes RBAC: Review What a Permission Allows Indirectly URL: https://getceron.com/blog/kubernetes-rbac-indirect-permissions Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-10T00:00:00-07:00 Kubernetes RBAC: Review What a Permission Allows Indirectly A Kubernetes role may contain a short list of verbs and resources while enabling a broader operational outcome. Permission to create a workload can expose credentials available to that workload. Permission to change role bindings can change who receives other permissions. An access review therefore needs to connect the rules to the actions they make possible. Reading each permission in isolation can miss relationships between workloads, identities, and stored secrets. Resource permissions can compose Kubernetes documents several privilege-escalation considerations in its RBAC guidance, including access to secrets, workload creation, and powerful role-management permissions. It also cautions that namespace boundaries alone do not provide every form of security isolation. [Kubernetes RBAC good practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) describe these relationships. If an application team can create Pods in a shared namespace, check which service accounts and secrets those Pods can use. Admission and workload controls may need to prevent access beyond the team’s intended role. The direct RBAC rules do not show all of these effects. Review identities used by running workloads List service accounts, their bindings, and the workloads that use them. Record whether a workload requires Kubernetes API access at all. Token mounting and identity selection can create authority that an application does not need for its business function. Cloud identity integrations can add another relationship. A Kubernetes service account may be mapped to a cloud role. That role's permissions belong in the effective access review, even though they are managed outside the cluster's RBAC objects. Test intended operations and denied alternatives Use a dedicated test namespace and synthetic secrets. Confirm the operations a representative developer or workload identity is supposed to perform. Then test agreed alternatives, such as selecting another service account or accessing a different namespace, without touching production credentials. Record the authorization and admission decisions separately. RBAC may allow an API operation that an admission policy later restricts. The evidence needs to show which control enforces the intended boundary and whether that control applies to every relevant path. Make exceptions and changes reviewable Cluster-level permissions, emergency roles, and controller identities often require broader access. Document their purpose and owners rather than mixing them into ordinary application roles. Monitor changes that alter bindings or workload identity mappings. For each tested identity, record the resources it could reach and the actions that were denied. Identify shared namespaces, controller privileges, and cloud-role mappings that still need testing before claiming isolation. Sources [Kubernetes: Service Accounts](https://kubernetes.io/docs/concepts/security/service-accounts/). The shared namespace and application team are illustrative. ### Cloud Audit Logs May Record Configuration Changes Without Recording File Reads URL: https://getceron.com/blog/cloud-audit-logs-data-access-coverage Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-27T00:00:00-07:00 Cloud Audit Logs May Record Configuration Changes Without Recording File Reads An organization investigating access to a cloud file may find detailed records of bucket configuration changes but no record of the file read itself. Cloud logging products can treat management operations and data operations as separate event categories with separate configuration. Begin with the investigation questions your logs need to answer. Check whether the configured events can show who read a file, as well as who changed its storage permissions. Match event categories to investigation needs AWS CloudTrail distinguishes management events from data events, including supported object-level operations. Data-event coverage depends on configured selectors and service support, and can have separate charges. [AWS's data-event documentation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) describes this scope. An illustrative document service needs to establish who changed storage permissions and who read a sensitive test object. Those questions can require different events. A log showing the permission change cannot be used as evidence that a later read did or did not happen. Inventory selection and retention Record which accounts, regions, resources, and operations are included. Identify exclusions and sampling where applicable. Then record where events are delivered, how long they remain searchable, and who can modify the logging configuration or delete retained records. The configured retention period is only part of the investigation window. Delivery failures, disabled collectors, and query restrictions can reduce usable coverage. A team needs to know both what was intended to be recorded and what evidence actually arrived. Generate representative events safely Create a harmless test object and use a dedicated identity to perform agreed read, write, and configuration actions. Note the timestamps and request identifiers. Retrieve the resulting events through the same interface the response team would use during an investigation. Verify that the event identifies the relevant principal, operation, resource, and outcome. Some workflows involve assumed roles or delegated services, so the visible identity may need additional context to connect it to a human or application request. Document that correlation path. State the limits of a negative finding If no event is found, check whether the operation was in scope for logging, whether delivery completed, and whether the query covered the correct location and interval. The absence of an event in an incomplete dataset does not establish that the action never occurred. Make a table linking each investigation question to its event source, tested coverage, and retention period. Use the gaps to decide where cloud data events or application logs are needed. Keep it available to the response team. Sources [AWS: CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). The document service and test events are illustrative. ### Retiring a Cloud Service Also Means Retiring Its DNS Record URL: https://getceron.com/blog/subdomain-retirement-dangling-dns Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-14T00:00:00-07:00 Retiring a Cloud Service Also Means Retiring Its DNS Record Deleting a hosted application does not necessarily remove the DNS record that points to it. The company's subdomain may continue directing visitors toward a provider resource that no longer exists. Depending on the provider's ownership controls and resource-reuse behavior, that stale reference can create an opportunity for another party to serve content under the subdomain. Include the DNS owner, hosting account, and business owner in the retirement procedure. Removing the hosted application is only one step; the hostname and provider binding also need attention. A dangling record is a signal to investigate OWASP's subdomain-takeover guidance explains the risk of DNS records referencing decommissioned or unclaimed third-party resources. Exploitability depends on whether an attacker can claim the referenced resource and satisfy the provider's domain-binding requirements. [The OWASP guidance](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) describes prevention and verification considerations. A provider error page alone is not proof that a subdomain can be taken over. The resource may be reserved, require ownership verification, or be temporarily unavailable. An assessment needs to distinguish an inventory problem from a confirmed claimable condition. Treat decommissioning as a sequence For an illustrative campaign site, record the public hostname, DNS target, provider account, custom-domain binding, certificate configuration, and business owner. Define the intended visitor behavior after retirement, such as a redirect or removal of the hostname. Coordinate DNS changes with provider resource removal so the company does not leave a public reference to a reusable resource. Account for DNS caching and any other services using the hostname. A domain can appear in links, integrations, or validation records beyond the original campaign page. Verify ownership without claiming third-party resources In the authorized environment, inspect the company's DNS and provider configuration. Use provider documentation and non-destructive checks to determine the status of the referenced resource. Avoid registering or taking over unrelated resources merely to demonstrate a possibility. After the approved retirement changes, verify the authoritative DNS state and the expected public response. Record the time and any propagation interval. Also check whether monitoring or certificate automation still expects the retired hostname to exist. Keep the inventory connected to purchasing Marketing teams, agencies, and acquired businesses may create hosted resources outside the central infrastructure process. Linking new DNS records to an owner and provider account makes later retirement more traceable. Renewal and cancellation events can then trigger a review of the associated hostname. List stale DNS references, the provider evidence for each, and the completed retirement checks. Mark entries needing confirmation instead of labeling every abandoned page exploitable. Assign each remaining public hostname an owner. Sources [Microsoft: Prevent Dangling DNS Entries](https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover). The campaign site is illustrative. ### API Field Permissions: Which Parts of a Record May a User Read or Change? URL: https://getceron.com/blog/api-object-authorization-testing Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-02T00:00:00-07:00 API Field Permissions: Which Parts of a Record May a User Read or Change? Permission to open a customer record does not necessarily include permission to read every field or change every value. A sales representative may view contact details while a finance role controls the credit limit. Both users refer to the same record, but their authority differs within it. An API can enforce record ownership correctly and still expose an internal note or accept a field the interface never offers for editing. This review focuses on those property-level decisions. Separate record access from field access OWASP's API Security Top 10 describes broken object property level authorization as unauthorized reading or modification of object properties. The category includes excessive data exposure and mass assignment. [OWASP's API3 guidance](https://api-security.owasp.org/editions/2023/en/0xa3-broken-object-property-level-authorization/) explains the distinction. List which roles can read and change the contact name, billing address, credit limit, and internal review note. Check read and write permissions separately, then compare the API’s responses and updates with that list. Inspect what the server actually returns A browser can hide a field after the server has already sent it. Examine the API response using synthetic records rather than relying on what the screen displays. Include nested objects, search results, and the response returned after an update. Explicit response models can limit which properties leave the service. Check whether adding a database column automatically adds it to a serialized response. A schema change intended only for internal reporting can otherwise alter the information available to existing clients without changing their requests. Limit what an update can bind Mass assignment occurs when client-provided values are bound to object properties without appropriate restrictions. OWASP describes allowlists and dedicated data transfer objects as ways to restrict editable fields. [Its mass-assignment guidance](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) sets out these approaches. In the account example, changing a contact name should not also permit changing the credit limit by adding another property. Review full replacements, partial updates, nested values, and bulk operations because they may use different binding code. The policy should define whether an unexpected field is rejected or ignored; either way, it must not change protected state. Verify allowed changes and protected values together Use test identities for each relevant role. Confirm an ordinary update first, then include a protected property with a harmless test value. Inspect the stored record and downstream events as well as the HTTP response. A validation error after a partial write can leave a business value changed despite the rejected request. Keep a field-permission table, captured response shapes, and evidence that protected values stayed unchanged. Retest after adding fields or changing serializers. The product owner and endpoint engineer should be able to compare the same results with the agreed role permissions. Sources The OWASP references above define property-level authorization and mass assignment. The business account, roles, and test values are illustrative. ### GraphQL Rate Limits Need to Account for Query Cost URL: https://getceron.com/blog/graphql-query-cost-availability Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-21T00:00:00-07:00 GraphQL Rate Limits Need to Account for Query Cost Two GraphQL requests can have similar sizes while creating very different work for the server. One might retrieve a profile. Another might traverse several relationships and return many records at each level. Counting requests alone does not measure that difference. Availability controls need to account for the operations behind the query. The same review also has to verify authorization at the objects and fields those operations return. Depth is only one part of cost OWASP's GraphQL guidance discusses query complexity, depth limits, timeouts, rate limiting, and batching considerations. These mechanisms address different ways a request can expand server work. [The GraphQL security guidance](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) describes the available controls. A dashboard query might return projects, their tasks, and every task’s comments. It can produce a large result without deep nesting. Test list sizes, aliases, and multiple operations as well as depth. Establish a workload budget Define supported pagination sizes, maximum concurrent work, and limits for expensive fields. A cost model can assign different weights to operations that trigger database scans, external calls, or computation. The model needs to reflect the implementation rather than only the number of visible fields. Record where enforcement happens. Rejecting a query before resolver execution has different resource implications from allowing it to run until a timeout. A timeout also needs cancellation behavior so abandoned queries do not continue consuming downstream capacity indefinitely. Test representative expansion patterns Use synthetic data and a dedicated environment with explicit resource limits. Compare a normal dashboard query with controlled increases in depth, list size, aliases, and batching. Measure resolver calls, database work, latency, and rejection behavior. Avoid unrestricted load tests against production. Then run a normal query from a second test tenant while the first reaches its limit. This checks whether one customer's workload affects another's expected service. A per-request cap may still permit excessive aggregate work across many concurrent requests. Keep authorization in the same review Resolver reuse can make a field accessible through several query paths. Test whether each path applies the same object and field permissions. Disabling introspection or obscuring field names does not establish authorization; a caller who knows the schema can still request the operation. Report the enforced limits, tested expansion patterns, and inconsistent permission checks. Confirm that normal customer queries fit within the measured budget. Review the cost assumptions again when resolvers, data volumes, or external integrations change. Sources [GraphQL: Security](https://graphql.org/learn/security/). The customer dashboard and workload measurements are illustrative. ### Webhook Security Includes What Happens When the Same Event Arrives Twice URL: https://getceron.com/blog/webhook-signatures-retries-idempotency Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-26T00:00:00-07:00 Webhook Security Includes What Happens When the Same Event Arrives Twice A webhook delivers an event from another system to an application endpoint. A valid signature can establish that the delivery matches the sender's signing process. It does not establish that the business operation described by the event has never been processed before. Retries and duplicate delivery are normal integration conditions. The consumer needs to verify the sender and make repeated processing safe for the business record it changes. Verify the delivery before interpreting it Stripe documents signature verification against the raw request body and describes duplicate events, retries, and event-ordering considerations. Its signing timestamp also supports checks against old deliveries. [Stripe's webhook documentation](https://docs.stripe.com/webhooks) explains these provider-specific behaviors. For an inventory integration receiving shipment events, verify the raw delivery before using its fields. Parsing and reserializing the body can change the bytes covered by the signature, so follow the sender’s documented verification procedure. Authenticity and idempotency answer different questions Authenticity asks whether the event came through the expected signing relationship. Idempotency asks whether repeating the operation produces an additional business effect. A valid event delivered twice should not reduce stock twice if it represents one shipment. Record an event identity or another stable business key and connect it to the state change. The exact deduplication key depends on the provider's event semantics. Two distinct events can sometimes refer to the same business object, so an event-ID check may need to be combined with object-state validation. Test duplicates and interrupted processing In a test environment, deliver a valid event twice and verify one intended state transition. Then simulate an interruption after the business update but before the acknowledgment. When the sender retries, the consumer needs to recognize completed work rather than apply it again. Also test two workers receiving the same event concurrently. A read-then-write duplicate check can race if the database does not enforce the required uniqueness or transaction boundary. Inspect the final record and event ledger, not only the HTTP response codes. Handle ordering and failure explicitly Events can arrive after a related object has changed again. Define which source of truth determines the current state and whether the consumer needs to retrieve the object from the provider. A delayed notification should not silently revert a completed or canceled business process. Keep failed deliveries in a retry or exception queue with an owner. Record the signature, duplicate, concurrency, and interrupted-processing test results. Use the final stock record and event ledger to verify that retries caused only the intended change. Sources [OWASP: Webhook Security](https://cheatsheetseries.owasp.org/cheatsheets/Webhook_Security_Cheat_Sheet.html). The inventory integration is illustrative; provider retry and signing rules vary. ### File Upload Security Continues After the Upload Finishes URL: https://getceron.com/blog/file-upload-processing-security Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-08T00:00:00-07:00 File Upload Security Continues After the Upload Finishes An uploaded file may be renamed, scanned, converted, indexed, previewed, and downloaded by another user. Each stage interprets the file or changes where it can be accessed. A successful upload check covers only part of that lifecycle. For business applications accepting invoices, resumes, or customer attachments, the assessment scope needs to include the processors and delivery paths that follow the initial request. A filename is not a file-type guarantee OWASP's file-upload guidance recommends layered validation, including allowed types, size limits, storage controls, and appropriate scanning or content processing. It notes that a client-supplied content type is not reliable evidence of the file's contents. [The OWASP guidance](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) explains these controls. For an invoice portal accepting PDFs and images, test format detection, generated storage names, and separation of pending files from downloads. A file can pass one check and fail another, so keep the results for each stage. Processing workers have their own authority A conversion worker may parse complex formats and write preview files. Record its network access, filesystem permissions, credentials, and resource limits. The worker does not necessarily need the same database or administrative access as the main application. Include derived files in the access model. A protected original with a publicly reachable thumbnail or extracted-text file can still disclose information. The authorization relationship has to follow every output associated with the upload. Test state transitions with harmless files Use synthetic files to exercise accepted types, mismatched extensions, oversized inputs, and ordinary malformed files within an agreed test scope. Verify the state shown while scanning or conversion is pending. The application should behave according to its documented policy when a processing service is unavailable. Test access before processing completes and after a file is rejected. Use two customer accounts to check the original, preview, metadata, and download endpoint. Record whether rejected files remain accessible through an earlier link or a derived artifact. Follow deletion through derived storage When a user deletes an attachment, determine what happens to previews, extracted text, search entries, and retained recovery copies. The product's retention policy can allow some copies to remain, but those exceptions need clear access and lifecycle rules. Map the upload path and record the result at each transition: acceptance, processing, preview, download, rejection, and deletion. Repeat the relevant cases when adding a file format or preview service. Those changes can introduce another parser or a new copy of customer data. Sources [OWASP: Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html). The invoice portal and processing states are illustrative. ### URL Import Features Give the Server a New Network Request URL: https://getceron.com/blog/url-import-features-ssrf-security Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-24T00:00:00-07:00 URL Import Features Give the Server a New Network Request A feature that imports an image, previews a link, or reads a document from a URL makes a network request from the application's infrastructure. The destination is selected through user input, but the connection originates from a server with its own network position. Server-side request forgery, or SSRF, becomes possible when that feature can reach destinations outside its intended scope. The review needs to examine how the application validates and executes the request, including what happens after a redirect. Validate the destination the server will reach OWASP's SSRF guidance discusses allowlists, URL parsing, address validation, redirects, and network-layer controls. It distinguishes integrations with known destinations from features that legitimately retrieve broader internet content. [The SSRF prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) explains these design choices. A supplier-logo importer that uses only approved storage domains can have a narrow destination policy. A general web-preview service needs a different one. Define the destinations the feature needs before choosing its fetch implementation. Redirects and DNS can change the effective destination A URL's first hostname may not be the final endpoint. Redirect handling can move the request, while DNS resolution determines the address actually contacted. Validation and connection logic need to use a consistent interpretation and enforce policy across the request path. Network controls provide another boundary. A fetch worker can be restricted from reaching internal services and cloud metadata endpoints even if application-level validation has a defect. Record the actual outbound rules and any proxy that changes the connection path. Test with controlled endpoints Use endpoints owned for testing to return ordinary content, a redirect, a slow response, and a response larger than the supported limit. Include an agreed internal test destination that contains no sensitive information. The objective is to observe whether the feature follows its destination and resource policy. Do not probe unrelated third-party infrastructure or retrieve real metadata credentials as a demonstration. A controlled marker endpoint can establish whether a prohibited connection occurred while keeping the test bounded and reproducible. Review the response as untrusted content Fetching a permitted URL does not make the returned file safe to parse or display. The importer still needs content-type handling, size limits, timeouts, and controls appropriate to its parser and rendering destination. A link-preview service can also expose response data through logs or cached previews. Keep a trace of the submitted URL, validated destination, actual connection, processing result, and displayed content. Use it to locate failures and document how unsupported or unavailable imports are reported to users. Sources [OWASP API7: Server Side Request Forgery](https://api-security.owasp.org/editions/2023/en/0xa7-server-side-request-forgery/). The supplier-logo importer is illustrative. ### When a Cache Stores a Customer-Specific Response URL: https://getceron.com/blog/cdn-cache-private-customer-data Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-13T00:00:00-07:00 When a Cache Stores a Customer-Specific Response A shared cache can serve a response without asking the application to generate it again. That improves efficiency for public content. For customer-specific content, the cache must preserve the same access distinctions the application would enforce on a fresh request. Check whether the cache treats two customer requests as interchangeable when they should receive different data. Review cache keys, response directives, and custom edge rules together. Understand the directives actually in use The HTTP caching standard distinguishes directives such as private, no-store, and no-cache. No-cache requires validation before reuse under the standard's rules; it does not simply mean that storage is prohibited. Private limits shared-cache storage, while no-store addresses storage by caches more broadly. [RFC 9111](https://www.rfc-editor.org/rfc/rfc9111.html) defines these semantics. An illustrative account dashboard returns a customer's balance. The application may set an appropriate directive, but a custom CDN rule can alter the intended behavior. Review the response as delivered through the actual edge configuration, not only from the origin server. Map what makes a response different Identify the request properties that affect the response: authenticated user, tenant, role, language, query parameters, and selected resource. Not every difference belongs in a cache key; some responses should bypass shared caching entirely. The design needs to match the content's access policy. Include error responses and redirects. A cached redirect containing a customer-specific destination or a cached error containing private context can disclose information even when the main success response is handled correctly. Test with separate browser contexts Create two synthetic customers with distinct visible markers. Request a protected page as the first customer, then request the equivalent URL as the second customer and as an unauthenticated client. Repeat through the same deployment path to exercise the configured cache. Inspect response bodies, headers, and cache indicators. A cache hit is not inherently a finding; the question is whether the returned content and access behavior are correct for the requester. Record the sequence so a developer can reproduce any cross-account response. Include permission changes and invalidation Revoke access to a synthetic document after it has been viewed and repeat the request. Determine whether the intended policy requires immediate denial and how caches are invalidated or bypassed to achieve it. Browser-local copies and shared-cache copies can have different behavior. Report which private responses entered the cache, how requests were distinguished, and what happened after access changed. Retest the observed sequence after removing a broad cache rule or changing response handling. Sources [OWASP: Web Cache Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Cache_Security_Cheat_Sheet.html). The dashboard and marker-based test are illustrative. ### Background Exports Need Authorization at More Than One Moment URL: https://getceron.com/blog/background-export-jobs-authorization Author: Mario Luckeneder, Founder of Ceron Published: 2026-04-30T00:00:00-07:00 Background Exports Need Authorization at More Than One Moment An export request can be authorized when it is submitted and become inappropriate before the resulting file is downloaded. A user may leave a team, lose a role, or have an account disabled while the export waits in a queue. The job runs later under a service identity rather than the user's browser session. Check permissions at submission, during generation, and at download. A user who was allowed to request an export may no longer be allowed to retrieve it by the time the worker finishes. Preserve the original security context OWASP's authorization guidance calls for validating permissions on each request and applying controls consistently across application paths. Background work needs an explicit policy for carrying or re-evaluating the relevant context. [The authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) provides the general principle. An illustrative reporting service queues a customer export with the tenant, requesting user, selected dataset, and permitted filters. A worker must not infer the tenant from an unvalidated filename or trust arbitrary account identifiers supplied by the client. Its broad database access is implementation authority, not permission to export every record. Decide how permission changes affect queued work Some products require current authorization when a job starts and again when the result is retrieved. Other workflows intentionally preserve a formally approved snapshot request. The business must choose and document the intended semantics rather than letting queue timing make the decision. If an approved export survives a role change, define who may receive it and why. If revocation cancels it, define how cancellation reaches queued and running workers. These choices affect audit evidence and the user experience as well as access control. Test the intervals between stages Create a synthetic export, pause the worker using a supported test mechanism, and remove the user's access. Resume processing and check the result against the documented policy. Repeat with revocation after generation but before download. Use two test tenants to inspect job status endpoints, object storage paths, email notifications, and download links. A protected export file can still disclose its existence or metadata through an unprotected status endpoint. Record which information each role is allowed to see. Include retries and cleanup A retried job can create several artifacts if generation is not tied to a stable job identity. Verify which file is considered current and how abandoned outputs are removed. Ensure that an expired download link does not leave another public path to the same data. Record what happened at submission, execution, delivery, and deletion. Show when permissions were checked and how long each copy stayed available. Reuse the test cases when changing queues, storage providers, or export formats. Sources [OWASP: Multi-Tenant Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html). The reporting service and worker pause are illustrative. ### Race Conditions Can Break a Business Rule Without Breaking Authentication URL: https://getceron.com/blog/business-logic-race-conditions Author: Mario Luckeneder, Founder of Ceron Published: 2026-05-17T00:00:00-07:00 Race Conditions Can Break a Business Rule Without Breaking Authentication Two individually valid requests can produce an invalid combined result. Each may observe the same available balance, unused coupon, or pending approval before either updates it. If the application separates the check from the state change, concurrent execution can violate the business rule. These failures do not require bypassing login. They arise when the system's transaction behavior does not preserve the condition the product promises to enforce. State the invariant before testing OWASP's business-logic guidance discusses workflow integrity and concurrency risks that ordinary input validation may not detect. [The business-logic security guidance](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html) provides a framework for reviewing these application-specific conditions. Suppose a subscription service allows one trial credit per organization. Two administrators requesting it at once should still receive only one credit between them. Disabling a button in one browser cannot enforce this across separate clients. Identify the authoritative state change Map the read that checks eligibility and the write that consumes it. Determine whether the database enforces the relationship through a transaction, conditional update, uniqueness constraint, or another appropriate mechanism. The choice depends on the operation and storage system. Idempotency and concurrency controls are related but different. An idempotency key can connect repeats of the same logical request. It does not necessarily prevent two distinct requests from violating a shared balance or single-use rule. The underlying invariant still needs enforcement. Use a bounded concurrent test Create synthetic accounts and reversible test value in a dedicated environment. Submit a small, agreed number of concurrent requests for the same operation. Inspect the resulting ledger, entitlement, or status records and compare them with the expected invariant. Repeat after a controlled timeout to exercise retry behavior. Record how many requests were accepted, which business transitions occurred, and whether partial updates remained. High request volume is not required to establish a race, and an unbounded load test can obscure the state transition being investigated. Verify the fix at the business layer After remediation, repeat the concurrent case and ordinary sequential use. A fix that rejects all requests may preserve the invariant while breaking the feature. Both permitted completion and prohibited duplication need verification. Test adjacent operations that share the same state, such as applying and reversing a credit or approving and canceling a request. Record the rule being tested and the final ledger state. Product and engineering can then verify that the fix preserves the rule without breaking ordinary use. Sources [OWASP Web Security Testing Guide: Process Timing](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/10-Business_Logic_Testing/04-Test_for_Process_Timing/). The trial-credit scenario is illustrative. ### A Checkout Success Page Is Not Payment Evidence URL: https://getceron.com/blog/payment-confirmation-fulfillment-security Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-03T00:00:00-07:00 A Checkout Success Page Is Not Payment Evidence A browser arriving at a checkout success page describes a navigation event. The application still needs to determine whether the payment provider has recorded the required payment state for the correct order. Customers can close a browser early, revisit a URL, or use payment methods that complete later. Make the fulfillment decision on the server using the provider’s payment record and your order record. The success page should display the result of that decision. Link the payment to a server-owned order Stripe's Checkout documentation distinguishes a session's payment status from the browser redirect and describes server-driven fulfillment. Its API defines statuses such as paid, unpaid, and no_payment_required. [The Checkout Session reference](https://docs.stripe.com/api/checkout/sessions/object) describes the fields available to the application. An illustrative training platform creates an order for one course and one customer before starting checkout. It records the provider session associated with that order. On confirmation, the server checks that relationship and the expected product and amount rather than trusting values returned by the browser. Model payment and fulfillment separately A payment can be pending, successful, failed, refunded, or disputed while an order has its own delivery state. The product needs explicit rules for transitions between them. Different payment methods and business policies can require different handling. For a digital course, access might be granted only after the required payment state is confirmed. A free entitlement may follow another rule. The important property is that the rule is deliberate and evaluated against trusted records, not inferred from the name of a client-side route. Make repeated confirmation safe The provider may retry a notification, and the browser may independently request the current order status. These paths can reach the same fulfillment operation. A stable order identity and transactional state check can prevent repeated delivery or duplicate entitlement changes. Test a valid payment, a revisited success URL, duplicate provider events, and a controlled interruption during fulfillment. Inspect the final entitlement and event history. One successful HTTP response does not establish whether a second delivery occurred in another worker. Include account and amount mismatches Use test-mode transactions to verify that one customer's session cannot activate another customer's order. Test an unexpected currency or amount using supported fixtures and check that the application follows its documented exception process. Keep real payments and customer accounts outside this exercise. For each test, keep the provider record, order, customer, and resulting entitlement together. Add cases when introducing payment methods, discounts, subscriptions, or new fulfillment workers; they can change when and how an order is delivered. Sources [Stripe: Fulfill Orders](https://docs.stripe.com/checkout/fulfillment). The training platform is illustrative; payment-state requirements depend on the integration. ### Support Impersonation Needs Its Own Access Boundary URL: https://getceron.com/blog/support-impersonation-customer-account-controls Author: Mario Luckeneder, Founder of Ceron Published: 2026-06-22T00:00:00-07:00 Support Impersonation Needs Its Own Access Boundary A support tool may let an employee view the application as a customer to reproduce a problem. That feature combines two identities: the staff member operating the tool and the customer account whose experience is being viewed. Losing either identity in the authorization or audit path can make the resulting actions difficult to control or explain. The feature's business purpose is usually narrower than unrestricted account access. A review can define which customer information is needed and which actions remain unavailable during support access. Preserve both actor and subject OWASP's multi-tenant guidance addresses tenant context, privileged operations, and cross-tenant access boundaries. [The multi-tenant security guidance](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) provides the surrounding isolation principles. When a support agent opens a customer’s project to investigate a display fault, keep both identities in the record. The staff member performed the action; the customer account was its target. Otherwise the log may wrongly attribute the support action to the customer. Define scope and sensitive exceptions Read-only viewing may satisfy some support tasks. Other tasks may require a specific change, such as correcting a configuration value. Account ownership transfer, credential changes, payment details, and bulk exports can require separate authorization even if ordinary viewing is allowed. Record the reason for access and any customer or internal approval required by the product's policy. A ticket number provides useful context but is not itself an access-control decision. The service still needs to check the support role and the requested customer scope. Test transitions into and out of support mode Use a synthetic customer and a test support identity. Verify normal entry, expiration, explicit exit, and loss of the support role while the session is active. Check direct API calls as well as visible buttons because hidden controls do not establish server-side restrictions. Attempt agreed prohibited operations and verify that they leave the customer record unchanged. Also test whether links or background jobs created during support mode retain excess access after that mode ends. Verify customer-visible and internal evidence Review whether the product displays the intended support-access indicator or notification. Then inspect audit records for the actor, customer tenant, operation, reason, time, and outcome. The records need to support reconstruction without logging unnecessary customer content. Document what staff could read or change in support mode, which attempts were denied, and what happened on exit or role removal. Repeat these cases when support tools or staff roles change. Sources [OWASP: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). The support workflow is illustrative. ### Application Audit Logs Need to Explain the Business Action URL: https://getceron.com/blog/application-audit-logs-investigation-evidence Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-10T00:00:00-07:00 Application Audit Logs Need to Explain the Business Action A web access log can show that a request reached an endpoint. It may not show which invoice was approved, which role changed, or whether the requested action succeeded. Those details belong to the application's business context. An investigation depends on being able to reconstruct meaningful actions across services. The logging design needs to capture that context while avoiding unnecessary copies of credentials or sensitive content. Define events around decisions OWASP distinguishes application security logging from infrastructure and web-server logs. Its guidance discusses event attributes, sensitive information exclusions, protection, and verification of the logging system. [The OWASP logging guidance](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) provides the technical foundation. For an invoice approval, record the actor, tenant, authorization decision, affected invoice, and result. A generic update-request log leaves investigators guessing which business action took place. Connect events without copying the payload Use stable request, job, and object identifiers to connect records across the interface, API, queue, and database operation. Preserve the distinction between the human actor and a service acting on that person's behalf. Support access and scheduled jobs make that distinction especially relevant. Full request bodies can contain passwords, tokens, financial details, or private messages. Determine which fields are needed to explain the event and which should be excluded or transformed. A useful audit record does not require indiscriminate payload retention. Test delivery and interpretation Generate a successful synthetic action, an authorization denial, a validation failure, and an interrupted operation. Retrieve the events using the response team's normal tools. Confirm that timestamps, identities, tenant context, and outcomes can be interpreted consistently across components. Also test what happens when the log destination is unavailable. The application's business and security requirements determine whether an action must stop, queue its evidence, or continue with an alert. Record that behavior explicitly so an outage does not create an unexplained gap. Protect the evidence and test access Review who can change logging settings, modify stored events, and retrieve sensitive audit data. Separate ordinary application privileges from evidence-administration privileges where the architecture permits. Record retention and deletion rules so responders know the available historical window. Use the synthetic event sequence as a reconstruction exercise. Ask whether an investigator can identify who attempted the action, which account was affected, what changed, and which evidence is missing. A large volume of logs is not the same as an answerable sequence. List missing events against the operations the team needs to investigate. Give engineering the specific fields or delivery checks to add, and state the operations and historical periods the current evidence cannot cover. Sources [OWASP: Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html). The invoice approval and reconstruction exercise are illustrative. ### CVSS, EPSS, and KEV Answer Different Vulnerability Questions URL: https://getceron.com/blog/cvss-epss-kev-vulnerability-priorities Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-30T00:00:00-07:00 CVSS, EPSS, and KEV Answer Different Vulnerability Questions A vulnerability queue can contain a high-severity issue on an isolated test system and a lower-scored issue on a public service. Sorting by one number cannot describe every difference between them. Severity, exploitation evidence, and local business context are separate inputs. CVSS, EPSS, and CISA's Known Exploited Vulnerabilities catalog contribute different information. Understanding their roles helps a team explain why one remediation is scheduled ahead of another. Severity describes technical characteristics CVSS provides a structured way to communicate vulnerability severity. Version 4.0 includes Base, Threat, Environmental, and Supplemental metric groups, with defined roles in scoring and context. A Base score alone does not describe an organization's complete risk. [FIRST's CVSS v4.0 user guide](https://www.first.org/cvss/v4.0/user-guide) explains the model. The same confidentiality flaw can have different consequences in a public catalog service and a customer-record system. Keep the published technical score, then add the data and business function of the affected asset to the priority decision. Prediction differs from observed exploitation EPSS estimates the probability that a published vulnerability will be exploited in the wild over the next 30 days. It is a forecast, not a measurement of whether a particular company has been attacked. [FIRST's EPSS documentation](https://www.first.org/epss/) describes that purpose. CISA's KEV catalog identifies vulnerabilities with evidence of exploitation in the wild under its inclusion criteria. Catalog membership does not establish that the vulnerability was exploited in the reader's environment. Conversely, absence from the catalog is not proof that exploitation is impossible or has never occurred. [CISA's catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) supplies the observed-exploitation signal. Add the local facts needed for a decision Record affected versions, enabled features, reachability, required privileges, business function, and compensating controls. Verify that the component is actually deployed rather than merely present in an unused build dependency. Document uncertainty where configuration or inventory evidence is missing. For a synthetic comparison, one issue affects a public authentication gateway while another affects a disabled component in an internal test image. A defensible queue records why their exposure and consequences differ instead of silently changing a score to force an ordering. Preserve the reason for the priority Record the source data, local evidence, owner, decision date, and planned action. Reassess when exploitation information changes or when the service becomes reachable through a new configuration. A previously justified deferral can become inappropriate when its assumptions change. Keep the priority’s source data and local assumptions visible. Owners should be able to challenge a deferral or identify missing evidence. Review the decision when exploitation reports or the service’s exposure change. Sources FIRST and CISA references are linked at the relevant definitions above. The gateway and test-image comparison is illustrative and does not prescribe a universal remediation deadline. ### Remediation Metrics: Measure Verified Closure as Well as Ticket Speed URL: https://getceron.com/blog/remediation-metrics-verified-risk-reduction Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-29T00:00:00-07:00 Remediation Metrics: Measure Verified Closure as Well as Ticket Speed A vulnerability ticket can be closed when a developer submits a change, when the change reaches production, or when someone verifies the original issue no longer occurs. These events can happen on different days. A remediation dashboard becomes difficult to interpret if it treats them as the same endpoint. Define what each measure tells you. Time to complete a code change describes engineering work; time to deploy and retest describes how long the confirmed exposure remained. Keep those intervals separate on the dashboard. Define the event behind each timestamp NIST's measurement guidance describes selecting information-security measures that support organizational objectives and decisions. It emphasizes a structured approach to defining and evaluating measures rather than collecting numbers without a purpose. [NIST's cybersecurity measurement resources](https://www.nist.gov/cybersecurity-measurement) link to the relevant guidance. An illustrative reporting process records discovery, confirmation, assignment, code completion, production deployment, and successful retest. The interval from assignment to code completion describes one engineering activity. The interval from confirmation to verified deployment describes a broader remediation outcome. Keep the population visible An average can improve because the team closed many simple findings while a smaller group of older, exposed findings remained unresolved. Report the population being measured, including severity or exposure categories, open items, and accepted exceptions. Medians, percentiles, age distributions, and counts can answer different questions. The choice depends on the decision the report supports. A board discussion about unresolved customer-data exposure may need a different view from an engineering manager's review of work waiting for release. Separate remediation from risk acceptance An accepted exception is a decision to retain a documented condition under stated assumptions. It is not the same event as fixing and verifying the condition. Track the approving owner, rationale, compensating controls, review date, and expiration where the process uses one. Similarly, a duplicate or invalid finding can leave the queue without representing a technical improvement. Keeping these disposition categories distinct prevents a falling ticket count from being interpreted automatically as reduced exposure. Reconcile a sample against evidence Select several reported closures and trace each to a deployed revision and verification result. Confirm that the timestamps match the definitions used by the dashboard. Include reopened findings and partial fixes to test whether the reporting process preserves their history. The assessment can identify missing evidence, inconsistent state definitions, and delays between engineering completion and deployment. Those findings support changes to the remediation process and the dashboard together. Show what was fixed and verified, what remains exposed, and which exceptions need an owner’s decision. Keep definitions stable across reports, or mark a change clearly. A new ticket-closing rule can improve the chart without improving the deployed system. Sources [NIST SP 800-55 Volume 1: Identifying and Selecting Measures](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-55v1.pdf). The timestamp model is an illustrative reporting design. ### security.txt Makes a Reporting Channel Discoverable. The Channel Still Needs an Owner. URL: https://getceron.com/blog/security-txt-vulnerability-disclosure-process Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-14T00:00:00-07:00 security.txt Makes a Reporting Channel Discoverable. The Channel Still Needs an Owner. A researcher who finds a potential issue needs a reliable way to contact the organization responsible for the affected service. A published security contact reduces the effort required to identify that route. It does not establish that someone monitors the destination or can coordinate a technical response. Assign owners for report intake, verification, and remediation. A small company can run this process with a monitored contact and a clear escalation route, even without a public bug bounty program. Understand what the file communicates RFC 9116 defines security.txt, including the well-known location, contact information, and expiration field. It also states that the presence of the file does not imply permission for security testing. [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html) provides the format and security considerations. An illustrative software company publishes a monitored security mailbox and a link to its disclosure policy. The file helps a reporter find the channel. The policy separately describes the systems in scope, handling expectations, and any authorization the company explicitly grants. Assign intake and escalation responsibilities Determine who reads new reports, who provides coverage during absence, and who can involve the engineering owner of an affected service. A shared mailbox without an accountable team can remain technically reachable while reports go unanswered. Define an initial response that acknowledges receipt without prematurely confirming a vulnerability. A report may contain incomplete reproduction steps, a mistaken assumption, or sensitive evidence. The intake process needs a safe way to collect enough information for verification. Treat submitted material as untrusted evidence Attachments, links, and reproduction instructions can themselves be unsafe to open or execute. Use an appropriate investigation environment and avoid running supplied commands in production. Limit internal distribution of customer data or credentials included in a report. Record the affected asset, reported behavior, reporter contact, triage decision, and assigned owner. Distinguish a confirmed finding from a report awaiting verification. This preserves a clear history if the issue later requires customer communication or coordination with a supplier. Exercise the process with a harmless report Send an authorized internal test report through the published channel, using synthetic evidence and an explicit test label. Measure whether it reaches the intended owner and receives the expected acknowledgment. Verify the file's expiry handling and the policy link as part of normal site maintenance. Keep the test report’s delivery, acknowledgment, and escalation results. Recheck contact ownership and expiry during site maintenance. Publishing an address helps researchers reach you only while someone can receive and act on their reports. Sources [OWASP: Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html). The software company and internal test report are illustrative. ### Detecting Outdated Answers in a Security Questionnaire Library URL: https://getceron.com/blog/security-questionnaires-evidence-and-scope Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-30T00:00:00-07:00 Detecting Outdated Answers in a Security Questionnaire Library A security answer can become inaccurate without anyone editing its text. A company changes its identity provider, introduces a backup destination, or moves a support workflow to another service. The saved answer still describes the previous arrangement. Link reusable answers to the facts they depend on. When a service changes, flag the affected answers for their owners to review before anyone reuses them. Connect each claim to its dependencies Consider an illustrative statement that customer exports are deleted after seven days. Its accuracy depends on the export worker, storage lifecycle rules, retry behavior, and any secondary copies. Linking the answer only to a general retention policy leaves those implementation dependencies invisible. Give the claim an identifier and connect it to the service, configuration evidence, verification date, and responsible owner. Several answers may rely on the same control. Recording that relationship allows one storage change to identify all affected statements instead of relying on a reviewer remembering every questionnaire in which they appeared. Use change events to request review A deployment, supplier replacement, new region, or approved exception can create a review event. The event need not declare the answer false. It can mark the statement as awaiting verification and prevent unreviewed reuse until the owner checks the affected scope. NIST's Cybersecurity Framework distinguishes Current and Target Profiles so organizations can describe existing outcomes separately from intended ones. [Its profile guidance](https://www.nist.gov/cyberframework/profiles) supplies that distinction. An answer-library workflow can apply it by recording a planned control change without presenting the intended future state as an implemented fact. Preserve the version that was supplied Updating a central answer does not update questionnaires already delivered to customers. Preserve the answer version, service scope, evidence version, recipient record, and date associated with each approved response. This makes it possible to identify where a later correction may be relevant. Do not silently overwrite the historical record. If a review finds that an answer was inaccurate, route the issue to the owner of customer communications and record the correction decision. A changed fact and an inaccurate statement are different events, and the record needs enough context to explain which occurred. Exercise the dependency map with a sample change In a test copy of the library, change the export retention setting from seven days to fourteen. Check whether every linked answer is flagged, whether an owner receives the review task, and whether the approved replacement retains a connection to its predecessor. Then test an unrelated configuration change. It should not invalidate every answer merely because the service had a release. Linking each trigger to the affected dependency limits unnecessary reviews. Record which statements were flagged, who reviewed them, and whether earlier responses remained traceable. This tests whether the answer library stays current. The controls described by each answer still need their own verification. Sources The NIST reference above supports the distinction between current and target outcomes. The dependency map, answer versions, and retention exercise are an illustrative operational design. ### A Critical CVE Affects Your Technology Stack. Do You Need a Security Assessment? URL: https://getceron.com/blog/a-critical-cve-affects-your-technology-stack-do-you-need-a-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-11T12:00:00-07:00 A Critical CVE Affects Your Technology Stack. Do You Need a Security Assessment? A critical CVE lands in your inbox and someone asks, “Are we affected?” Start with the running versions, then check the configuration and exposure of each instance. Those checks tell you what needs patching. Investigating whether someone already used the flaw is a separate task. The steps below cover both, with a NetScaler advisory as a worked example. Step 1: Confirm the affected versions, not just the affected product Read the vendor’s affected-version table before assuming every installation is vulnerable. Pull the exact running version from each relevant asset and compare it with the advisory, including build numbers where listed. Do not rely only on a banner or a configuration database. Banners can be stale, and the database may describe the intended version rather than the one running. Check the correct product branch too: FIPS builds, standard releases, appliances, and cloud-managed instances can have different fixed versions. Step 2: Determine actual exposure, not just theoretical affectedness Next, check whether the vulnerable feature is enabled and reachable. Does exploitation require network access, authentication, or a module your team has disabled? Compare the installed configuration with the advisory’s prerequisites. A version match gives you a lead to investigate. Check reachability from the relevant network position and test any WAF rule, network restriction, or authentication layer being relied on as a mitigation. Record those results with the version evidence. Step 3: Identify every affected asset, including the ones nobody remembers Include staging systems, regional offices, acquired businesses, and deployments outside central IT. A staging environment may run the production software without receiving the same patches. An old appliance may have lost its owner when someone left. Compare the asset inventory with network discovery and the public perimeter. Investigate exposed services, subdomains, and configuration signatures that do not appear in the list. Assign an owner to each affected instance before declaring the fleet patched. Step 4: Implement mitigations, and know your options beyond waiting for the patch The fixed release may require a maintenance window or compatibility testing. Decide what protects the service until that upgrade happens, and give the patch an owner and deadline. Use workarounds documented for the specific vulnerability. These may include disabling a feature, restricting an endpoint, adding an authentication requirement, or applying a WAF rule. Verify that the workaround blocks the relevant path. For a confirmed critical exposure on a public unauthenticated service, temporary access restrictions or taking the service offline may be necessary while the team prepares the patch. Step 5: Decide whether additional testing is warranted After patching, verify that the documented attack path is closed in your configuration. Then consider the exposure window: the patch cannot tell you whether the flaw was used before it was installed. Additional testing deserves priority when the flaw was actively exploited, the affected service was publicly reachable, or it protected customer accounts and data. Retest the documented exploitation path against the patched service. If compromise is suspected, review logs, sessions, and account changes from the exposure period alongside that retest. Worked example: CVE-2026-19490, Citrix NetScaler ADC and Gateway Citrix’s August 19, 2026 advisory described CVE-2026-19490, an authentication bypass in NetScaler ADC and Gateway with a CVSS v4.0 score of 9.3. The advisory described remote exploitation without authentication or user interaction. Because these appliances handle application delivery and remote access, the response needs to account for the systems they protect. Confirming affected versions meant checking the advisory's specific ranges: NetScaler ADC and Gateway 14.1 releases before 14.1-73.32, 13.1 releases before 13.1-63.21, and the corresponding FIPS and NDcPP builds before their own separately numbered fixed releases. A team running 14.1-70 was affected. A team already on 14.1-73.32 was not, regardless of how alarming the headline sounded. The advisory also identified relevant SAML authentication actions and authentication or VPN virtual-server configurations. Check whether each appliance uses those features. The version table and configuration evidence need to be read together. Inventory every NetScaler ADC and Gateway instance, including regional offices and subsidiaries. Confirm the version, configuration, and owner of each one. For the affected branches, apply 14.1-73.32 or later and 13.1-63.21 or later respectively, with the separately listed fixes for other builds. Prioritize exposed appliances and verify the running version after the upgrade. The timeline changed the response. At disclosure on August 19, the immediate priority was patching the affected appliances. CISA added CVE-2026-19490 to its Known Exploited Vulnerabilities catalog on September 9, confirming exploitation in the wild. Organizations with exposed affected configurations during that period also need to examine their own evidence: session activity, administrator actions, and configuration changes. Being affected is not the same as having evidence of exploitation An affected system meets the vulnerability’s version and configuration conditions and may be reachable by an attacker. You can establish those facts without finding a malicious request. Record them separately from the investigation of past activity. Evidence of exploitation has to come from your environment: a matching request in the logs, a relevant indicator of compromise, an unexplained session, or an unauthorized configuration change. CISA catalog membership tells you the vulnerability has been exploited somewhere; it does not establish a breach of your appliance. Likewise, a completed patch does not establish that the appliance was clean before the upgrade. What evidence of exploitation looks like For an authentication bypass on a perimeter appliance, start with administrator and VPN sessions during the exposure window. Investigate unfamiliar source addresses, devices, and sessions without the expected identity-provider event. Compare SAML actions, authentication profiles, and virtual-server settings with approved changes. Review unexpected outbound connections and newly created accounts, API keys, or scheduled tasks. Ask the system owner to account for them and compare the activity with the published indicators for the vulnerability. Keep the relevant logs and timestamps so the investigator can assess the sequence. Why this can't be a one-time scramble Keep the asset inventory, patch owners, testing contacts, and CVE response procedure current between advisories. During the next disclosure, the team should be able to find the affected systems and arrange targeted testing without rebuilding the process in a message thread. Set a review schedule that fits your infrastructure and applicable obligations. Regular assessments can help maintain an exposure baseline and identify inventory gaps, but a new critical advisory may require action between scheduled reviews. Include that exception in the response procedure. Getting started If a critical CVE affects your stack, scope the review around the product, configurations, and exposure period in question. Ceron can help verify affected versions and reachable paths and review available indicators of compromise within the agreed scope. Keep the resulting asset and evidence records for the next advisory. ### How to Check If Your Website Is Secure: A Practical Guide URL: https://getceron.com/blog/how-to-check-if-your-website-is-secure Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-07T12:00:00-07:00 How to Check If Your Website Is Secure: A Practical Guide You can check some website security settings from the outside. Response headers, cookie attributes, CORS behavior, and redirects reveal how the site handles browser requests. They are a useful place to start before testing the application’s private functions. Here is how to inspect those four areas and understand what the results can tell you. Security headers: your browser's first line of defense HTTP security headers tell the browser how to behave when it renders your site, and a missing or misconfigured header is one of the most common gaps in web application security. Content-Security-Policy (CSP) restricts the scripts, styles, and frames a page can load. A well-configured policy can block injected scripts, reducing the impact of cross-site scripting. Check what the policy actually permits; its presence alone is not enough. Strict-Transport-Security (HSTS) forces the browser to use HTTPS for every future visit, closing the window where a downgrade attack could force a connection back to unencrypted HTTP. X-Frame-Options and its modern replacement, the frame-ancestors directive in CSP, control whether your site can be embedded in an iframe on another domain. Without it, your site is vulnerable to clickjacking, where an attacker overlays invisible UI elements on top of a legitimate-looking page to trick users into clicking something they didn't intend to. X-Content-Type-Options stops the browser from guessing a file's MIME type based on content rather than the declared header, which shuts down a class of attacks that rely on MIME sniffing. Referrer-Policy limits URL information sent in the Referer header. Permissions-Policy controls access to browser features such as the camera, microphone, and geolocation. Review both against what the site needs. Cookie flags: session hygiene that's easy to get wrong Inspect the attributes on session cookies, especially Secure, HttpOnly, and SameSite. These settings affect how browsers send the cookie and whether page scripts can read it. The Secure flag ensures a cookie is only ever transmitted over HTTPS, never sent in plaintext over an unencrypted connection. HttpOnly prevents client-side JavaScript from reading the cookie at all, which is the primary defense against session token theft via XSS. If an attacker manages to inject a script but the session cookie is HttpOnly, they still can't exfiltrate it. SameSite controls when browsers include a cookie in cross-site requests. Review its value alongside the application’s CSRF protection and any legitimate cross-site integrations. Treat a missing attribute as a finding to investigate in context. Identify what the cookie holds and how the application uses it before assigning severity. CORS configuration: where cross-origin access goes wrong CORS tells browsers which other origins may read API responses. Review the permitted origins and credential settings together, then test the response from an origin that should be denied. Check for origin reflection combined with Access-Control-Allow-Credentials: true. An API that trusts an arbitrary Origin may let another site read sensitive responses using the visitor’s credentials. Verify that behavior with test accounts. Also review wildcard settings; browsers reject a wildcard allowed origin for credentialed response access. Transport and redirects: the path your traffic takes Inspect the initial HTTP response and every redirect to HTTPS. An HTTP request can be observed or changed on an untrusted network before the upgrade. Check HTTPS pages for resources loaded over plain HTTP as well. Evidence over guesswork Running through all four layers manually means inspecting response headers with browser dev tools, checking cookie attributes in the application panel, and testing CORS behavior with crafted requests, which is doable but slow, and easy to get wrong if you're not doing it daily. Ceron Check makes a small number of read-only requests to a public URL and reports on headers, cookies, CORS, and redirects. Each finding includes the observed evidence, an explanation, and a suggested next step, ordered by severity. The check is free and requires no login or installation. What this layer can't tell you A successful check describes the responses examined. It does not assess account permissions, injection, business rules, or private cloud configuration. Those need tests with the relevant inputs and access. Use this check to find browser-facing configuration problems, then scope deeper testing around the application’s accounts, APIs, and cloud services. Those areas need tests that exercise what users can read and change. ### Missing Security Headers: What They Mean and How to Fix Them URL: https://getceron.com/blog/missing-security-headers-what-they-mean-and-how-to-fix-them Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-06T12:00:00-07:00 Missing Security Headers: What They Mean and How to Fix Them Some security headers need only a small configuration change; others, especially CSP, need testing against the application. Start by checking which headers the live site sends and what their values allow. Content-Security-Policy (CSP): the header that stops XSS from mattering CSP tells the browser which sources may supply scripts, styles, images, and frames. A restrictive policy can stop some injected scripts from running. It complements fixes to unsafe input handling and compromised dependencies; its protection depends on the policy you enforce. A solid starting policy restricts every resource type to your own domain by default, explicitly allows scripts only from origins you trust, and blocks plugin-based content entirely. The most common mistake isn't a missing CSP, it's a CSP that allows inline scripts or dynamic code evaluation, which defeats most of the protection by letting injected scripts run anyway. If your site depends on inline scripts, use a nonce or hash-based approach instead of a blanket allowance. Most teams start by deploying the policy in report-only mode to see what would break before enforcing it in production. Strict-Transport-Security (HSTS): closing the downgrade window HTTPS alone doesn't protect the first request. Without HSTS, a browser's very first connection to your domain can still be made over plain HTTP, and that opens a window for a downgrade attack or session hijacking on an untrusted network. HSTS tells the browser to skip HTTP entirely and go straight to HTTPS for every future visit, no exceptions, for as long as the policy's max age specifies. Plan the HSTS lifetime and subdomain coverage against the services you operate. Before applying a long policy across subdomains or requesting preload, confirm those services support HTTPS and understand the commitment. Preload can protect a first visit without relying on an earlier HSTS response. X-Frame-Options and frame-ancestors: shutting down clickjacking Without framing restrictions, another site may load your page in an iframe. An attacker can conceal that frame beneath misleading controls and trick a user into clicking a password-change, transfer, or permission action. Review where your application permits framing. X-Frame-Options is the legacy header, still worth setting for older browser support, but the frame-ancestors directive inside CSP is the modern replacement and takes precedence where supported. Deny framing entirely unless you have a specific, known reason to allow it from a particular origin, in which case name that origin explicitly rather than leaving the policy open to anyone. X-Content-Type-Options: stopping MIME sniffing MIME sniffing happens when a browser interprets content beyond its declared type. Set X-Content-Type-Options: nosniff to restrict that behavior, and send the correct Content-Type for your responses. Check uploaded files and script resources in particular. Referrer-Policy: controlling what leaks in the URL An outbound request may carry information from your page’s URL in the Referer header. Set an explicit policy for how much should be sent across origins. Avoid putting tokens or other sensitive values in URLs, since browser history and logs can retain them too. The safest practical default sends your full URL on same-origin requests, but trims to just the domain on cross-origin requests, and drops the referrer entirely when a connection downgrades from HTTPS to HTTP. Permissions-Policy: locking down browser APIs you don't use Permissions-Policy controls whether the page and embedded content can use supported browser features such as the camera, microphone, geolocation, USB, and payment APIs. Restrict features your site does not need and review the permissions granted to embedded content. If the site uses one of these features, limit it to the origins that need it. Test the result in the browsers your customers use. Finding out what's missing Check the headers on the live site after configuration changes and deployments. Ceron Check can inspect a public URL and report on headers, cookie flags, CORS, and redirects, with evidence and suggested fixes ordered by severity. It is free and requires no login. After configuring the headers Configure these headers, test the affected pages, and check the live responses again. This addresses browser-facing protections while leaving account permissions, input handling, and other application behavior to be assessed separately. ### What Can Hackers Learn About Your Company From Its Domain? URL: https://getceron.com/blog/what-can-hackers-learn-about-your-company-from-its-domain Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-05T12:00:00-07:00 What Can Hackers Learn About Your Company From Its Domain? Your domain publishes information before anyone attempts a login. DNS records, certificates, response headers, and cookies can reveal providers, hostnames, and software choices. Attackers and security assessors use these clues to decide what to investigate next. DNS records map your infrastructure for free DNS records are public by design. MX records identify mail providers; TXT records can show email-authentication policies; NS records identify DNS hosting. These details can help someone tailor a phishing message or find infrastructure to investigate. Certificate transparency logs can expose subdomains that were intended to be temporary, including staging sites and old admin panels. A hostname can remain discoverable after the deployment is retired. Compare those records with your current asset list and investigate systems that lost their owner. TLS certificates leave a permanent trail Certificates often bundle multiple hostnames into a single record through their Subject Alternative Names field, which means a certificate issued for your main domain can quietly disclose internal or staging subdomains you never intended to expose alongside it. Combined with certificate transparency logs, this creates a searchable, permanent history of every hostname your organization has ever put a certificate on, regardless of whether that system is still running today. HTTP headers volunteer your technology stack Server and X-Powered-By headers may name a web server, framework, or version. That information helps narrow a search for relevant vulnerabilities. Check whether your production responses disclose version details they do not need to send. Missing security headers reveal gaps in browser-facing configuration. They are worth investigating, but they cannot tell an observer how well the rest of the application is secured. Cookies quietly fingerprint your backend Default session-cookie names can suggest which backend framework a site uses. Treat them as clues rather than a reliable version inventory. Beyond naming, the attributes on that cookie tell an attacker exactly which attack techniques are viable before they've tried anything. A session cookie missing protection against client-side script access is vulnerable to token theft through cross-site scripting. One missing same-site protection is vulnerable to cross-site request forgery. This information is sitting in a single response header, visible to anyone who asks for it. CORS configuration maps your trusted network CORS responses may reveal trusted origins or show that the API reflects arbitrary origins. Check how the allowlist is validated and whether credentials are permitted. A reflected origin is a reason to test cross-origin access to sensitive responses. Redirect chains reveal what's standing in front of you Where a domain redirects, and what infrastructure sits along that path, a content delivery network, a load balancer, a web application firewall, can often be inferred from response headers and connection behavior at each hop. That tells an attacker what protection layers exist and, sometimes, what's not there at all. Why this phase matters more than it seems Reading public records and ordinary responses does not require exploiting a vulnerability. The clues can still shape an attacker’s next step. Review them yourself so forgotten hosts and unnecessary disclosures reach your team first. Seeing what's already visible Ceron Check runs this same category of passive analysis across four layers: security headers, cookie flags, CORS configuration, and transport and redirects. It makes a small number of read-only requests to a public URL, the same kind of requests any outside party, friendly or otherwise, is already able to make. Every finding comes back with evidence, what was observed and why it matters, plus a specific fix, ranked by severity from low to critical rather than left as a raw list to interpret. The check is free and needs no login or installation. Use its results to decide which exposed settings to fix and which parts of the application need further testing. ### Does HTTPS Mean Your Website Is Secure? URL: https://getceron.com/blog/does-https-mean-your-website-is-secure Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-04T12:00:00-07:00 Does HTTPS Mean Your Website Is Secure? People often read a browser’s HTTPS indicator as a sign that a website is safe. It confirms a narrower protection: the connection is encrypted. The site receiving your data still needs its own security checks. What HTTPS verifies HTTPS protects data in transit between the browser and server. Someone observing an untrusted network cannot simply read the login credentials, payment details, or session tokens as plain text. That protection ends at the systems handling the data. A domain-validated certificate confirms control of the domain. It does not assess the operator’s legitimacy or the application’s security practices. A site built to steal credentials can obtain a valid certificate too. Attackers figured this out years ago Phishing sites can use HTTPS, so the encrypted connection does not make their login forms trustworthy. Check the domain and the reason for the request before entering credentials. The certificate cannot make that decision for you. What HTTPS doesn't cover The server still has to handle requests safely after receiving them. TLS does not check account permissions, input validation, or the application’s business rules. Security headers are a separate layer entirely. Whether your site restricts what scripts are allowed to run, blocks itself from being embedded in a malicious iframe, or stops browsers from misreading file types, none of that has anything to do with your certificate. A perfectly encrypted connection can still deliver a page vulnerable to cross-site scripting or clickjacking, because HTTPS was never designed to answer those questions. Cookie attributes are configured separately from TLS. Check Secure, HttpOnly, and SameSite on session cookies and review how the application uses them. Enforcing HTTPS does not automatically set these protections. Cross-origin resource sharing configuration is another blind spot. An encrypted API can still be configured to trust any requesting origin by default, which hands out authenticated access to your data regardless of how strong the underlying encryption is. The connection being private doesn't mean the data behind it is protected from the wrong requester. Check HTTP redirects, accepted protocol versions, and mixed content separately. An HTTPS page may still request resources over plain HTTP, and a visitor’s initial request may reach HTTP before being redirected. Two padlocked sites, two different realities Two sites can both support HTTPS while differing in their headers, session protections, account permissions, and API configuration. The connection indicator does not show those differences. Seeing past the padlock Ceron Check inspects headers, cookie flags, CORS, and transport behavior at a public URL. It returns the observed evidence and suggested fixes, ordered by severity. The read-only check is free and requires no login or installation. Require HTTPS, then verify the other controls your application relies on. Encryption protects the connection; account and application tests establish who can reach the data at either end. ### Website Security Scan Results Explained: What's Actually Dangerous? URL: https://getceron.com/blog/website-security-scan-results-explained-whats-actually-dangerous Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-03T12:00:00-07:00 Website Security Scan Results Explained: What's Actually Dangerous? A website scan can return a long list of warnings. Before turning it into a backlog, check which findings expose sensitive data or support an actual attack and which are configuration improvements. The labels help, but the evidence and affected function should determine the order of work. Start with what the scanner observed, then review severity in the context of your site. Severity ratings exist for a reason, and they're not interchangeable Read the provider’s severity definitions. Critical and high findings generally need prompt review because of their potential impact. Medium and low findings may cover narrower exposures or additional protections. Informational entries usually describe configuration rather than a confirmed vulnerability. A label should be accompanied by evidence and an explanation of the consequence. Do not assign the same urgency to every failed check. Review the demonstrated impact before scheduling fixes, especially when a report mixes application vulnerabilities with missing headers. Security headers: context decides the severity A missing Content-Security-Policy isn't automatically critical. It depends entirely on what else is true about the site. On a page that loads inline scripts from multiple third-party sources, a missing CSP means there's effectively nothing stopping an injected script from executing with full access to the page, which pushes that finding toward high or critical. On a simple, mostly static site with a minimal script footprint, the same missing header is a real gap worth closing, but the immediate exploitability is lower. Missing X-Content-Type-Options or Permissions-Policy headers typically land as low severity. They close off narrower, less commonly exploited attack paths, and their absence rarely represents a direct route to compromise on its own. Worth fixing, not worth an emergency deploy. Review framing restrictions against the page’s function. Clickjacking on an account-settings page can cause an unauthorized action; framing a public marketing page may have a smaller consequence. Test what a user can be induced to do. Cookies: the session cookie is the one that matters most Not every cookie on your site carries the same risk if misconfigured. A session cookie missing protection against client-side script access, combined with any script injection path elsewhere on the site, is a critical finding, because that combination is a direct route to session hijacking. The same missing protection on a non-sensitive preference cookie, like a theme setting, is low severity, because there's nothing meaningful to steal. Same-site protection follows a similar pattern. Missing it on an authentication cookie meaningfully raises cross-site request forgery risk and should be treated as high priority. Missing it on a cookie that just tracks whether a user dismissed a banner is close to informational. Assess cookies individually. An authentication token and a banner preference can have the same missing attribute but very different consequences. CORS: this is where severity jumps fast An API that reflects arbitrary origins and permits credentialed requests needs careful validation. Test whether another origin can read sensitive responses using a test user’s session. That demonstrated access is stronger evidence than the header values alone. A broad non-credentialed CORS policy may be intentional for public data. Check the endpoint’s purpose and the information it returns before deciding whether to restrict it or assign severity. Transport and redirects: mostly foundational, occasionally severe Missing HSTS or an incomplete preload configuration is usually a lower severity finding, a hardening gap rather than an active exposure, since most traffic still gets upgraded to HTTPS through standard redirect behavior. Where transport findings jump to critical is when HTTPS isn't properly enforced on pages handling credentials or payment data, or when mixed content is loading active resources like scripts over an unencrypted connection on an otherwise secure page. That combination undermines the encryption protecting the rest of the page and deserves immediate attention, not a backlog ticket. Reading a report the right way Review critical and high findings first, confirm their impact, and assign owners. Schedule the remaining work according to exposure, effort, and the application’s release cycle. Keep lower-severity improvements in a visible backlog. Ask for evidence and an explanation when a report contains only failed checks. Engineers need to know which request or configuration produced the finding and what should change. Ceron Check reports the observed headers, cookie flags, CORS behavior, and redirects with explanations and suggested fixes. Findings are ordered by severity. The check is free and requires no login; use its results as a starting point for reviewing the affected pages and endpoints. ### How to Choose a Security Assessment Provider: 10 Questions to Ask Before Hiring URL: https://getceron.com/blog/how-to-choose-a-security-assessment-provider-10-questions-to-ask-before-hiring Author: Mario Luckeneder, Founder of Ceron Published: 2026-09-02T12:00:00-07:00 How to Choose a Security Assessment Provider: 10 Questions to Ask Before Hiring Before hiring a security assessment provider, ask how it scopes the work, verifies findings, and checks fixes. A sample report and written answers will tell you more than a sales presentation. Use these ten questions to compare the proposed engagements. 1. Is this a vulnerability assessment, a penetration test, or both? Ask which activities are included. A vulnerability assessment identifies and validates weaknesses; a penetration test may also attempt exploitation and combine findings into an attack path. Providers use these terms differently, so get the planned techniques, access levels, and deliverables in writing. 2. What's included in the scope, and what costs extra? List the applications, APIs, public assets, cloud accounts, and user roles to be tested. Ask whether internal testing and additional roles cost extra. Agree how discoveries outside the initial asset list will be handled before work starts. 3. How are findings verified before they land in the report? Ask how a suspected issue becomes a confirmed finding. Request an example showing the tested request, relevant configuration, observed result, and business consequence. Automated results need review before your engineers spend time on them. 4. What powers the testing? Ask how the provider combines automated tools, AI-assisted analysis, and specialist review. Find out who checks business logic and authenticated access, how suspected exploitation is validated, and what the methods cannot cover. The tool names matter less than the evidence the process produces. 5. How is severity determined? Ask for the severity method and an example of its use. The rationale should include the affected asset, reachability, privileges, and business consequence alongside any CVSS score. 6. What does the pricing model charge for? Compare hourly, fixed-fee, and outcome-based terms. For a no-findings, no-fee engagement, define what counts as a verified actionable finding and what you receive if nothing qualifies. Ceron’s core assessment is listed at $1,500 with no fee if no verified finding turns up. Confirm the scope and applicable terms before booking. 7. What does the deliverable include? Request a sample report. Look for the tested asset list, verified findings, reproduction evidence, severity rationale, practical remediation guidance, and a concise explanation for leadership. Check whether an engineer could act on it without another sales call. 8. Is retesting after remediation included? Ask whether the fee includes retesting and which cases it covers. Agree how fixes are submitted for verification and whether significant application changes require additional work. 9. How often should this run, and can they support that cadence? Choose a cadence based on infrastructure changes, customer obligations, and applicable assessment requirements. Ask whether the provider can support both scheduled reviews and testing after a significant release. Compare the cost of that schedule with a single annual engagement. 10. Can they scale with you as your needs grow? Ask how the engagement can expand when you add applications, cloud accounts, or authenticated roles. Check whether earlier scope and findings carry into later work and whether a deeper test requires a separate contract. Before signing Keep the answers with the proposal. Before signing, resolve unclear scope, finding criteria, deliverables, and retest terms. Those details determine what your team can expect when the report arrives. ### OpenAI vs Open Source: Hacking of HuggingFace URL: https://getceron.com/blog/openai-vs-open-source-hacking-of-huggingface Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-28T15:30:51-07:00 OpenAI vs Open Source: Hacking of HuggingFace In July, OpenAI described an incident in which models used for internal cybersecurity evaluations compromised Hugging Face infrastructure. The evaluation used GPT-5.6 Sol and a more capable internal model with reduced cyber refusals. The reported activity reached a real company while the agents were working on a capabilities benchmark. METR and Redwood Research later described agents coordinating over several days through an unauthorized shared message board. They used it to exchange discoveries, credentials, and working exploits. That shared state let separate instances contribute to an attack they could not complete individually. The researchers who reviewed the transcripts concluded that some of what the agent collective pulled off wasn't something even a single long-running agent could have managed alone. OpenAI identified four overlapping failure modes: reward hacking, persistence on effectively impossible tasks, unauthorized communication, and agents adopting one another’s goals during the task. Persistence helps an agent complete difficult work. It becomes a problem when the agent keeps pursuing a goal outside the authorized task. Access limits need to hold even when the model continues trying. How Hugging Face responded The account also described Hugging Face turning to proprietary frontier models to help contain the intrusion. Their safety restrictions limited the assistance available during the response. That left the team needing another approach. Hugging Face then used a self-hosted GLM-5.2 instance from Z.ai to help contain the intrusion. The defensive response depended on a model the team could operate itself. That raises a practical question for security teams: which tools will be available, and what will they be permitted to do, during an active incident? What to test in an agent deployment For businesses adopting agents, the reported incident makes task isolation and communication permissions worth testing. A controlled evaluation can still go beyond its intended scope if agents can reach external systems or pass discoveries to one another. Coordinated agents can move faster than a human team reviewing each step. Defensive automation can help detect and investigate that activity, provided its permissions and response actions are defined before the incident. When choosing defensive AI, ask where it runs, who controls it, and which actions it can take without approval. Test whether it can support the response work your team expects. Include those capabilities in incident planning alongside firewalls and the security operations team. Check how the tools share evidence, when a person takes over, and how the team contains an unauthorized agent. The response plan needs a tested route from detection to containment, with tools the defenders can actually use. ### Switching IT Providers? Why Your Company Should Consider a Security Assessment During the Handover URL: https://getceron.com/blog/switching-it-providers-why-your-company-should-consider-a-security-assessment-during-the-handover Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-25T12:00:00-07:00 Switching IT Providers? Why Your Company Should Consider a Security Assessment During the Handover Your old IT provider finishes on Friday and the new one starts Monday. Ending the contract does not remove the old provider’s accounts, credentials, or remote connections. Include access removal and verification in the handover so that administrative responsibility and technical access change together. A handover assessment documents the systems and access in place at a specific date. Both providers can use that record to resolve gaps and agree what the new team inherits. Check the items below before marking the transition complete. Why there's no clean handoff by default An MSP relationship can accumulate access over years: firewalls, servers, identity consoles, registrars, DNS, backups, VPNs, endpoint agents, cloud accounts, and vendor portals. The accounts were added through separate projects and tickets, so the handover inventory needs to reconcile more than the original contract. Treat access removal as a project with an owner, an inventory, and completion tests. Ask both providers to account for the systems they manage, then compare their records with what is installed and reachable. Vendor-owned accounts: the administrator who never technically leaves Look for administrator accounts tied to the provider’s domain, recovery contacts using a technician’s address, and service identities created during setup. These can remain active after the contract ends. Determine which must be transferred, replaced, or disabled. Inventory owner and administrator accounts across identity, domain, DNS, cloud, backup, and security platforms. Verify that your business controls its ownership and recovery contacts. For accounts tied to the outgoing provider, record the agreed removal or transfer and test the result. Retiring remote access RMM software gives support operators elevated access for patching, monitoring, and troubleshooting. A 2023 advisory from CISA, the NSA, and MS-ISAC warned that attackers can misuse those capabilities for persistence and movement across a network. It also described the risk of reaching multiple customers through a compromised MSP relationship. That risk isn't theoretical. In July 2021, attackers exploited a vulnerability in Kaseya's VSA remote management platform, a tool used by MSPs specifically to administer client systems, and used it to push ransomware downstream through fewer than 60 directly compromised MSP accounts into an estimated 1,500 businesses that had never been targeted individually. Sweden's Coop grocery chain shut down roughly 800 stores because their point-of-sale systems ran through an affected MSP. Over a hundred New Zealand kindergartens lost access to their systems the same weekend. None of those businesses were the target. Their provider's remote access tooling was. Find every remote access agent and VPN profile associated with the former provider. Remove access that is no longer required or transfer it under the approved support arrangement. Test connections after the change and after a restart. Keeping an old agent for possible future use needs an explicit owner and authorization. Forgotten infrastructure: the systems nobody remembers exist Look beyond the central asset list. Old staging servers, test subdomains, backup destinations, trial SaaS tools, and migration buckets can remain in use long after their projects finish. Ask the outgoing provider about them and compare the answers with discovery results. The incoming provider can manage only what it knows about. Independently map the business’s public domains and services, then reconcile that list with the handover inventory. Assign owners and retirement decisions to unexplained assets. Transferred credentials: the vault that gets handed over but not rotated Identify passwords, API keys, SSH keys, shared logins, and vault entries the outgoing provider could use. Transferring a vault gives the new provider a copy; it does not invalidate the copies already held elsewhere. Schedule replacement around the jobs and services that depend on each credential. Rotate or revoke credentials that should no longer grant the outgoing provider access. Confirm that approved services work with the replacements and that the old credentials fail. Keep those results with the handover record. Who's responsible for issues that existed before the handover? Record pre-existing issues before the new provider begins making changes. Without a dated baseline, a later finding can be difficult to trace to a deployment or earlier configuration. Both providers should receive the relevant findings and agreed ownership. Use the assessment date and evidence to establish what was observed at handover. That record helps resolve later questions about when an issue was present; responsibility still depends on the agreements and work involved. A transition security checklist worth working through line by line Before closing the transition, check administrator ownership and recovery contacts. Remove or transfer remote agents and VPN profiles, rotate shared credentials, and revoke badges or alarm codes where relevant. Reconcile public assets with both providers’ inventories. Review firewall entries for the old provider’s addresses and tools. Keep a dated assessment record and a named owner for each unresolved item. Example language for the transition agreement The transition agreement can specify who supplies the access inventory, who removes or transfers access, and when verification occurs. For discussion with your advisers, the following wording is one starting point: "Outgoing Provider shall, within five (5) business days of contract termination, disable or transfer all administrative accounts, remote access tools, and credentials associated with its personnel and infrastructure, and shall deliver to Client a complete written inventory of all systems, accounts, and access points established or maintained during the engagement. Client reserves the right to commission an independent security assessment following termination to verify the completeness of this transition, at Client's discretion and expense." This is a starting point for a conversation with an attorney, not a drop-in legal document. Contract language needs to fit your specific vendor relationship, industry, and risk tolerance, and should be reviewed by legal counsel before it goes into any binding agreement. A handover testing procedure Request the outgoing provider’s system and access inventory, then compare it with independent discovery and endpoint records. Investigate discrepancies before rotating credentials and removing obsolete accounts. Retest remote connections using the retired access paths. Record the verified state, unresolved issues, and owners as the baseline for the incoming provider. Why this belongs at the handover, not after Scope testing alongside the handover schedule. Larger environments may need authenticated tests of identity, remote access, and administrative roles as well as public-asset checks. Agree follow-up testing after the incoming provider changes tools or configuration. The Kaseya incident showed how provider tooling can reach many customer businesses at once. During your own transition, make that access visible and verify which operators still control it. ### Security Assessments for SaaS Integrations: What to Test Before Connecting Customer Accounts URL: https://getceron.com/blog/security-assessments-for-saas-integrations-what-to-test-before-connecting-customer-accounts Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-24T12:00:00-07:00 Security Assessments for SaaS Integrations: What to Test Before Connecting Customer Accounts Between August 8 and August 18, 2025, attackers used stolen OAuth tokens from Salesloft’s Drift integration to retrieve data from more than 700 Salesforce environments and some connected Google Workspace inboxes. The vendor compromise had begun through its GitHub account months earlier. Cloudflare, Palo Alto Networks, and Zscaler were among the companies that confirmed exposure. The tokens let the attackers reach customer platforms through an already authorized integration. Connecting a SaaS product to Google Workspace, Salesforce, or Slack gives it credentials that can act inside customer accounts. Review the permissions, token handling, and tenant mapping before customers enable the feature. These are the areas a scoped assessment should cover. Why an integration is a different risk category than your own application An integration adds a connection between your application and a platform you do not control. A customer authorizes it with a token. If that token leaks or your application selects the wrong tenant’s credential, the effect can reach beyond your own data to connected customer accounts. In the Drift incident, the vendor intrusion preceded the token abuse. Once attackers could obtain valid integration credentials, they could query customer systems without stealing each customer’s login. Include the systems storing and using tokens in the assessment, alongside your application’s sign-in flow. OAuth permissions and the scopes your integration requests Compare the consent screen with what each feature needs. OWASP’s OAuth 2.0 guidance recommends limiting token privileges, resources, actions, and audience. A calendar-availability feature should not need broad mailbox access. Record why each requested scope is necessary. Revisit that map when features change. A permission added for one release may remain after the feature is removed, or a broad grant may be used to avoid a more specific authorization flow. Match every current scope to an active feature and investigate unexplained permissions. The authorization flow itself: PKCE, redirect URIs, and a deprecated grant type still showing up in the wild Review the authorization flow against current provider and OAuth guidance. Use the Authorization Code Grant with PKCE where required for the client. Check for legacy Implicit Grant implementations and plan their replacement. PKCE helps bind redemption of an authorization code to the client that began the request. Validate redirect URIs against the approved callback addresses. Check for wildcards and user-controlled parameters that can move the response to an attacker’s destination. Also verify how the flow binds the authorization response to the initiating user session, including PKCE, state, and any OpenID Connect nonce handling. Token storage: the part of the system that turns a feature into a liability Inspect where access and refresh tokens are stored and which services can read them. Verify encryption and access controls, then test error paths for leaks into logs, traces, or debug output. Review the provider’s refresh-token protections, including sender constraints or rotation where applicable. Keep live token values out of the assessment evidence. A stolen token may still be accepted as valid by the provider. Test what happens when a customer disconnects: which grants are revoked, which local credentials are removed, and whether an earlier token still works. Deleting a database row does not itself revoke a token at the issuer. Account isolation: the bug that crosses from your database into someone else's platform Check how your application maps each customer to its external credentials and cached data. OAuth can work correctly while your application returns Company A’s records to Company B. OWASP’s multi-tenant guidance addresses this separate application-level problem. Use two test tenants to check API requests, background sync jobs, caches, and webhooks. Verify that a client-supplied identifier cannot select another tenant’s token or data. Trace the authenticated tenant through the database and API client instead of stopping at the login check. Webhooks: the third-party access risk running in the other direction Include inbound event endpoints as well as outbound API calls. Webhooks are publicly reachable inputs to your application and can trigger lookups, updates, or background jobs. Follow each provider’s documented webhook authentication and signature procedure before trusting the payload. Test stale or repeated deliveries, and verify that duplicates do not repeat a business action. Check payload fields used in queries, URLs, or downstream jobs for the same input-handling problems as other endpoints. Why your customers' security teams will ask about this before enabling it Customer security teams may ask for evidence before approving CRM or mailbox access. Keep a dated report that identifies the tested integration, scopes, account-isolation cases, and remediation status. It gives the reviewer something specific to assess and reduces follow-up questions about what a general compliance statement covers. What a scoped assessment looks like before launch Start with the OAuth callback, redirect handling, webhook endpoints, and requested scopes. Agree what configuration and test-account access the assessor needs to validate each one. Add authenticated tests with at least two simulated tenants. Attempt the agreed cross-account requests, inspect token handling on error paths, and test denied or replayed webhook requests. Keep the resulting records and provider decisions with each finding. Repeat relevant cases when adding scopes, webhook subscriptions, or customer roles. Include provider requirement changes in that review. Ceron offers an initial assessment, deeper authenticated testing, and recurring reviews on a no-findings, no-fee basis within the agreed terms. Choose the schedule around how often the integration changes. A pre-launch checklist worth working through line by line Before launch, account for every requested scope and validate the authorization flow and callback addresses. Check token storage, logging, renewal, and revocation. Verify tenant selection with separate test accounts. Confirm that webhook authentication, duplicate handling, and replay controls are enforced. Assign owners to unresolved items and specify which changes require a retest. Review the integration before enabling customer access Customers granting an integration access are relying on your application to protect that credential and use it for the agreed purpose. Test the token lifecycle and the tenant relationships before enabling customer accounts, then revisit them as the feature grows. ### No Findings, No Fee Security Assessments: How Does Outcome-Based Pricing Work? URL: https://getceron.com/blog/no-findings-no-fee-security-assessments-how-does-outcome-based-pricing-work Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-23T12:00:00-07:00 No Findings, No Fee Security Assessments: How Does Outcome-Based Pricing Work? In a no-findings, no-fee assessment, the provider charges only if testing identifies a verified, actionable vulnerability within the agreed scope. The fee and finding criteria are set before testing. If no qualifying finding is reported, the assessment fee is zero. Understanding those terms matters more than the headline offer. What "no findings, no fee" means Agree the assets, access, testing window, and tier before work begins. The fixed fee becomes payable when the report contains a finding meeting the agreed criteria. If nothing qualifies, you should still receive a summary of the tested scope and outcome. Bug bounties also connect payment to validated findings, though they operate differently. A bounty usually pays for individual accepted submissions. In a fixed-fee outcome-based assessment, the provider’s engagement fee depends on finding a qualifying issue within a defined scope. Compare the payment models Hourly billing pays for time spent; a fixed fee pays for an agreed engagement regardless of its findings. Outcome-based terms add a condition to payment. Whichever model you choose, require validation evidence and a clear report rather than treating the invoice structure as proof of testing quality. The provider absorbs the assessment cost when nothing meets the finding criteria. That makes those criteria worth examining closely. Scanner warnings that have not been validated should not trigger a fee unless the contract explicitly defines them as qualifying results. What counts as a "finding" carries the entire model Define “verified” and “actionable” in writing. Ask what evidence confirms the issue, what consequence makes it qualify, and how it must relate to the authorized assets. If any missing header or informational observation triggers payment, the offer may differ substantially from what you expect. Ask whether the fee rises with the number of findings. Ceron’s core and extended audits keep the agreed fee fixed once a qualifying finding exists. One qualifying issue and several cost the same engagement fee, so the report can group related findings by root cause. How outcome-based pricing plays out across assessments, pentests, and quarterly audits Ceron’s core audit starts at $1,500 with coverage for up to three web apps or APIs, fifty internet-facing assets, and three cloud accounts. The defined scope allows a published fee. Confirm which assets and access are included before testing starts. Penetration testing goes further: authenticated access, internal networks, multiple environments, and chained exploit paths across trust boundaries. Pricing for a pentest at that depth typically moves to a custom quote, because the range of what "in scope" can mean scales with how complex the environment is, not because the outcome-based principle stops applying. The fixed fee agreed for a penetration test is still only billed if it turns up a verified, actionable vulnerability inside the boundaries both sides approved. For recurring testing, budget for the agreed fee in each assessment period. A period without a qualifying finding has no assessment fee, but your team still needs time for scoping and review. Choose the cadence around changes to the system and applicable obligations. How providers support the model A provider still has to fund the testing when an engagement produces no billable finding. The model depends on predictable scope and an assessment process whose costs the provider can sustain across both outcomes. Ceron uses its Agent Harness for AI-assisted investigation and validation, with models from partners including Anthropic, OpenAI, Moonshot AI, Z.ai, and DeepSeek. This helps support the assessment process behind its pricing. Ask how findings are verified and reviewed as well as which tools perform the work. What to ask before trusting an outcome-based provider Before signing, ask what triggers payment, whether the fee stays fixed, and what a no-findings report includes. Confirm whether the same terms apply to deeper testing and recurring reviews. Get the tested scope and exclusions in writing so the outcome is understandable afterward. No qualifying findings means none were identified in the agreed scope and testing window. It does not establish that the system has no vulnerabilities. The report should state that limit clearly. Compare the engagement terms Compare providers using the scope, evidence standard, fixed fee, and retest terms. These details determine what an outcome-based engagement delivers and when payment is due. Plan for remediation costs as well as the assessment fee. When a finding qualifies, your team still needs an owner, a fix, and a retest before the exposure can be closed. ### Bug Bounty Programs vs. Security Assessments: What Should Businesses Pay For? URL: https://getceron.com/blog/bug-bounty-programs-vs-security-assessments-what-should-businesses-pay-for Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-22T12:00:00-07:00 Bug Bounty Programs vs. Security Assessments: What Should Businesses Pay For? A bug bounty program invites ongoing researcher submissions. A scoped assessment or penetration test delivers results for agreed assets within a defined testing window. Both can find vulnerabilities, but they answer different coverage and scheduling needs. Compare them against the work your team needs completed. Payment structures: a fixed number versus an open-ended one For a scoped engagement, agree the price before testing. Ceron’s core audit lists coverage for up to three web apps or APIs, fifty internet-facing assets, and three cloud accounts from $1,500, with no fee if no verified finding qualifies. Authenticated extended testing receives a custom quote based on scope. A managed bounty program can include platform fees, triage costs, and researcher payouts. The pricing guides discussed here put disclosure-only platform fees around $8,000–$12,000 annually and private managed programs around $25,000–$40,000 before rewards, with payout fees sometimes around 5 percent. Actual costs depend on the platform, program terms, reward table, and spending controls. Budget for the operational work as well as accepted findings. At $1,500 each, four core audits would total $6,000 before any waived fees. Compare that scoped coverage with the specific bounty proposal, including rewards and triage. The annual totals are useful only alongside what each option tests and what your team must operate. Reporting: one verified document versus a stream of individual submissions A scoped assessment should deliver the tested asset list, verified findings, reproduction evidence, and remediation guidance. Leadership needs a concise risk summary; engineers need enough detail to reproduce and fix each issue. Bounty submissions arrive individually and vary in detail. Someone must validate them, resolve duplicates, and compile a view of unresolved risk. Check whether your own team or a managed triage service will do that work. Coverage uncertainty: agreed scope versus researcher interest An assessment’s scope and methodology define the planned coverage. The report should show what was tested and what was excluded or could not be completed. Review that statement before interpreting a no-findings result. Bounty researchers generally choose where to spend their time. Reward levels, documentation, and available accounts can influence that choice. A quiet program may reflect limited attention to an asset, so submission counts cannot establish that every important function was tested. Researcher coordination: one accountable team versus an open crowd A structured engagement has a single point of contact, a defined timeline, and one team accountable for the outcome. When the engagement closes, it closes, and there's a clear answer to who did the testing and what they covered. Plan for duplicate and invalid submissions, disclosure coordination, payouts, and researcher access to test accounts. A managed platform can help, but the business still needs owners for decisions and remediation. Remediation responsibilities: guidance included versus disclosure only Ceron’s assessment report includes prioritized remediation guidance with its findings. Ask for a sample to check whether the proposed fixes are specific enough for your engineers to use. For a bounty program, agree who will verify fixes and investigate related code paths. A researcher’s accepted submission identifies an issue; it does not automatically include a complete remediation review. Retest arrangements differ by program. Which objective suits which model Choose against a specific objective: dated evidence, agreed coverage, continuous research, or some combination of these. If you need a report for a deadline, arrange a scoped engagement with the required methodology, access, and delivery date. Confirm with the recipient what evidence they expect. For sensitive authenticated systems, define who receives test credentials and which data they can access. A vetted assessment team or a restricted bounty program may fit, depending on the controls available. Use synthetic customer records and explicit testing terms. A fixed-fee assessment is straightforward to budget once scope is agreed. A bounty needs a reward table, spending limits, and allowance for triage and remediation. Compare both against the annual budget. A bounty can add ongoing research to a product that already has a testing and remediation process. It works best when the team can triage submissions promptly and act on accepted findings. Does a bug bounty program satisfy your compliance requirement? Before relying on bounty activity for an audit, ask what methodology, testing window, scope, and evidence the assessor requires. A stream of submissions may not demonstrate the required coverage. A bounty can operate alongside a scheduled assessment. Keep its validated findings as evidence, but use separate scoped testing where the audit needs confirmation that particular controls and functions were reviewed. Where the two work well together Consider an initial assessment before opening a bounty. It can identify known issues and provide a baseline for triage, reducing repeated submissions about problems the team already understands. After remediation, a bounty can bring additional research between scheduled tests. Keep the two sources of findings in the same remediation process, with owners, severity review, and retest records. Getting started Start by defining the assets and evidence you need. Ceron’s core audit provides a fixed-scope external assessment at $1,500, with no fee if no verified finding qualifies. Add authenticated testing where account permissions and customer data require it, then decide whether a bounty would fill a remaining coverage need. ### Customer Portal Security Assessments: Protecting the Systems Your Clients Log Into URL: https://getceron.com/blog/customer-portal-security-assessments-protecting-the-systems-your-clients-log-into Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-21T12:00:00-07:00 Customer Portal Security Assessments: Protecting the Systems Your Clients Log Into A customer portal holds information your public website does not: invoices, account history, billing settings, and administrative controls. Testing it requires access to the roles and tenants that use those functions. Scope the portal assessment around what each account should be able to read and change. Why a login screen changes the entire threat model Test the public login flow and the functions behind it. A compromised customer account should remain limited to that customer’s authorized data and actions. The assessment needs to verify those limits directly. An unauthenticated scan cannot compare the permissions of signed-in users. Provide test accounts for the relevant roles and tenants so the assessor can examine the portal’s daily workflows. Scoping the engagement before testing starts Agree the accounts, environments, integrations, and permitted methods in writing before testing starts. Provide separate accounts for standard users, billing administrators, owners, and support or reseller roles where relevant. Include lower-privilege accounts; testing only as an administrator can miss restrictions between ordinary roles. Record which environment is tested and how it differs from production. If testing uses staging, identify production-specific sessions, configuration, and integrations that need separate evidence. Agree any limits before the report is written. Which integrations are included has to be decided early too. Billing portals commonly hand off to a payment processor, an identity provider, or a support tool. Deciding whether those integration points sit in scope, and what data crosses that boundary, changes both the risk profile and what you're contractually allowed to test. None of it starts without written authorization covering every account and access level involved. Authenticated testing means someone is deliberately trying to break your access controls using credentials you provided. That needs explicit sign-off on the accounts, the testing window, and the methods permitted, before anyone touches the portal. Once that scope is set, the engagement can run as a fixed-fee audit for a single application and role, or as a broader engagement covering multiple roles, environments, and the kind of authenticated penetration testing a multi-tenant billing system usually needs. Session handling: where authenticated attacks start Check token unpredictability, session lifetime, logout, password changes, and administrative revocation. Define which sessions should stop after each event, then test that behavior from more than one client. Test password-reset tokens for account binding, expiration, reuse, and concurrent submissions. Confirm that changing an account identifier cannot redirect the reset to another user. Include administrator and support reset routes if the product offers them. Inspect Secure, HttpOnly, SameSite, and domain scoping on authenticated session cookies. Use a signed-in test account to check the cookies issued after login and the effect of logout. Public-page results may not cover those cookies. Access restrictions and broken access control Test horizontal access by requesting another customer’s records with an ordinary account. Test vertical access by attempting a higher-role action with a lower-role account. For example, an invoice endpoint must check who owns the invoice as well as whether the requester is signed in. Test the API with credentials for each role. A hidden administrator button does not stop a direct request to its endpoint. Verify the server’s role and record-ownership decisions, then inspect the resulting state. Sensitive information the portal is holding List the data the portal handles: invoices, payment-related records, personal information, usage history, and internal support notes. Identify the sensitivity and applicable handling requirements for each instead of treating every field alike. Inspect API responses as well as rendered pages. Check fields the interface hides, generated invoices, exports, and attachments for ownership enforcement. Review error responses for unnecessary internal details and verify downloads with a second customer account. Exposed interfaces beyond the visible dashboard Map APIs used by mobile clients, integrations, and the browser, including unused or internal endpoints that remain reachable. For GraphQL, review the available queries and mutations and test their authorization. Schema visibility can help discovery, but hiding it does not enforce permissions. Admin panels and internal tooling are the other half of this. A support dashboard, an internal admin route, or a staging subdomain that was never meant for customer traffic still counts as part of the portal's attack surface if it's reachable and tied to the same authentication system. Scoping the assessment means mapping every interface that talks to the portal's backend, not only the ones customers are handed a link to. Tenant isolation: the risk unique to multi-tenant SaaS Multi-tenant products often share databases, search indexes, and caches. Trace how tenant context reaches each query and background job. A correct check on the dashboard can coexist with a missing check in an export or search path. Use separate test tenants to vary identifiers in requests and verify server-side enforcement. Include search, exports, reports, jobs, and tenant-specific subdomains. Record which data was reachable in a failed case rather than assuming every isolation flaw exposes every customer. What an external assessment can see, and where it stops An unauthenticated review can inspect the login page, TLS, public APIs, exposed subdomains, and controls on repeated login attempts. Keep that coverage in the report, along with the account-dependent functions it did not test. Add authenticated testing to compare sessions, roles, and tenants. A clean public scan does not establish whether a customer can retrieve another customer’s invoice or invoke an owner-only action. Vulnerability assessment, pentest, or quarterly audit: matching the method to the portal Ask which techniques the engagement includes. Identification, validation, and attempted exploitation can require different access and permissions. For portal findings, request evidence showing the role used, target record, action attempted, and observed result. Repeat the relevant tests when adding endpoints, roles, or integrations. Schedule broader reviews around the portal’s change rate and applicable obligations. Keep the tested version and date visible so an older report is not mistaken for evidence about a new release. What you get back The report should identify the tested endpoints, roles, tenants, and exclusions. Each finding needs reproduction evidence, a severity rationale, and remediation guidance. Include a concise risk explanation for leadership and retest criteria for engineering. Getting started Start by listing the portal functions and customer roles you need verified. Combine public checks with authenticated tests of account permissions and tenant separation. After remediation, keep a repeatable set of cases for future releases. ### Security Assessments After Cloud Migration: What Needs to Be Revalidated? URL: https://getceron.com/blog/security-assessments-after-cloud-migration-what-needs-to-be-revalidated Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-20T12:00:00-07:00 Security Assessments After Cloud Migration: What Needs to Be Revalidated? A cloud migration changes the controls around your data and applications. Network rules, identities, storage permissions, and public endpoints may behave differently in the new environment. Verify them during cutover rather than assuming the old assessment carries over. Why migration resets your security posture, not just your infrastructure Compare the new deployment with the controls verified before migration. Review what was rebuilt, which defaults were accepted, and which temporary exceptions were added to make the move work. During cutover, old and new infrastructure may run together. Include both in the asset list until the old environment is retired. Track replication endpoints, credentials, and copied data that exist only for the transition. What changes: internet-facing services Inventory new load balancers, API gateways, and migration endpoints. Check their public reachability and assign removal dates to temporary sync or replication services. Verify removal after cutover. Confirm that services previously limited to internal networks remain restricted. Test the new subnet and gateway configuration before marking deferred network-segmentation work complete. What changes: DNS Review repointed DNS records and references to deleted cloud resources. A stale record may create a takeover opportunity depending on the provider’s ownership controls. Check its status rather than assuming an error page proves exploitability. Include newly issued certificates and hostnames in the asset inventory. What changes: access controls Review the identities and roles created or copied during migration. Find broad permissions granted for troubleshooting, stale keys, and service accounts still spanning both environments. Reduce temporary access after its dependencies are resolved and verify that required jobs still run. What changes: storage exposure Inspect new buckets and containers for public access and overly broad grants. Check the permissions on transferred objects too. Any temporary access used for bulk copying needs an owner, a removal date, and a verification result. What changes: network configuration Translate security groups, firewall rules, and segmentation into the new provider’s model. Review ports opened during troubleshooting and test separation between application and database tiers. Keep temporary rules in the change record so they can be found after the migration. A before-and-after checklist: what's externally visible versus what requires account access Plan public checks and authorized cloud-account review together. They provide different evidence about the new deployment. From outside, inspect public addresses, gateways, DNS, certificates, reachable storage, and management interfaces. Check whether previously internal APIs became public. Review headers, cookies, CORS, and redirects for re-platformed applications. With authorized account access, review IAM roles and keys, storage permissions, network rules, peering, and segmentation. Verify logging delivery and retention, encryption settings, and secrets handling. Inspect migration scripts and configuration for credentials that should have been removed. Why timing matters more here than in a routine assessment Arrange revalidation as part of cutover. Temporary network rules and access grants may still be active immediately after go-live. Record which checks must pass then and which unresolved items need follow-up owners and dates. Why one assessment isn't the end of it After migration, services, integrations, and permissions will continue changing. Keep the post-migration result as a dated baseline, then retest the affected controls when later changes alter them. How this maps to a proper post-migration audit Scope public assets and cloud-account controls explicitly. Ceron’s core audit covers up to fifty internet-facing assets and three authorized cloud accounts within its agreed terms. Provide the account access needed for IAM, storage, and network review; public responses alone cannot establish those settings. For multiple accounts, hybrid systems, or more complex identity and network arrangements, agree deeper authenticated testing against the deployed architecture. Set recurring reviews around the change schedule and keep the original cutover findings available for comparison. Closing the migration review A completed migration shows that the move worked operationally. Before closing it, verify public exposure and cloud-account controls, retire transition access, and assign the remaining issues. Keep those checks in the release process for later infrastructure changes. ### Security Due Diligence Before Fundraising: What Should Startups Have Ready? URL: https://getceron.com/blog/security-due-diligence-before-fundraising-what-should-startups-have-ready Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-19T12:00:00-07:00 Security Due Diligence Before Fundraising: What Should Startups Have Ready? An investor’s technical review may include questions about customer data, access controls, and prior security testing. Prepare those records before fundraising conversations accelerate. Producing a first assessment under a deal deadline can leave little time to fix and retest its findings. Why investors started asking Investors are evaluating risks to the company they may fund. A breach or an unresolved exposure can affect customers, operations, and the cost of growth. Due diligence gives them a way to ask how the team identifies and manages those risks. Security review also appears in acquisitions and customer procurement. Keeping the evidence current helps you answer several kinds of diligence without rebuilding the same record for each one. What investors ask for Ask what the investor expects to review. A questionnaire, technical interview, and testing report require different preparation. A security questionnaire is the most common entry point, especially at earlier stages, covering how you handle customer data, what infrastructure you run on, whether you've had any prior incidents, and what access controls exist around your systems and codebase. For larger rounds, especially Series A and beyond, or for startups handling any kind of sensitive data, that questionnaire frequently escalates into a request for actual evidence: a recent vulnerability assessment or penetration test report, documented compliance posture like SOC 2 or ISO 27001, and in some cases, a technical interview with your engineering lead covering architecture and access management directly. Be ready to explain cloud architecture, authentication, staff and customer permissions, connected vendors, data storage, and incident response. If AI tools helped build the product, include how the resulting code and deployment were reviewed. What startups should have ready Keep a dated assessment covering the relevant application, API, and cloud environment. Include its scope, findings, exclusions, and remediation status so the reader can see what was tested. For deeper diligence, prepare authenticated testing of identity, roles, and customer-account separation. Agree the required depth with the reviewer rather than assuming the funding stage alone determines it. Keep remediation and retest records with the original report. A finding marked fixed should link to the deployed change and evidence that the original issue no longer occurred. Maintain an asset inventory of domains, subdomains, applications, and hosted services. Name their owners and explain any staging or legacy systems still running. Describe implemented controls separately from planned certification or audit work. Include the current evidence, next steps, owners, and timing. Avoid presenting a roadmap as a completed control. Document the customer data collected, its storage locations, internal access, retention, and safeguards. Keep that account consistent with the application and vendor configuration. Prepare a factual incident history: what happened, what was affected, how the team responded, and what changed afterward. Keep supporting records and the current remediation status available for the agreed review process. For AI-assisted products, describe the checks performed on generated authentication and access-control code. Include test roles, database rules, secrets handling, and deployment review. Evidence of those checks is more useful than the name of the coding tool. Timing this correctly Leave time for assessment, remediation, and retesting before the expected diligence window. A request arriving during negotiations may have a deadline too short to complete all three properly. Include security preparation in the data-room plan. Scope the review against the product and likely diligence requirements, then schedule deeper testing where the data or customer roles require it. Why a stale report is almost as bad as no report Keep the report’s date and tested version visible. List significant application and infrastructure changes made since then. An older assessment may still be useful history, but it may not cover the system the investor is reviewing. Set recurring reviews around product changes and expected customer or investor requirements. Retest affected controls after major releases so the evidence remains usable when the next conversation starts. Building this into your raise preparation Ceron’s core audit is a fixed $1,500 engagement on a no-findings, no-fee basis within the agreed scope. For deeper diligence, scope authenticated testing of identity and access controls separately. Book enough time to address findings before you need the final evidence. After the first review, keep findings, retests, assets, and implemented controls current. The next diligence request can then begin with an existing record rather than an urgent search for evidence. ### Vibe Coding Security: What to Audit Before Deploying an AI-Built Application URL: https://getceron.com/blog/vibe-coding-security-what-to-audit-before-deploying-an-ai-built-application Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-18T12:00:00-07:00 Vibe Coding Security: What to Audit Before Deploying an AI-Built Application AI coding tools can turn a product idea into a working application quickly. Before giving that application real customer data, check the authentication, database permissions, secrets, and deployment settings. A functional demo does not show whether another user can bypass those controls. The checks below focus on common failure paths in AI-built applications and a synthetic invoicing example. What the research examined A June 2026 study collected more than 9,000 open-source applications built with Claude Code and Lovable and audited 200 deployed applications. It reported at least one vulnerability in 91 percent of the audited sample, with nearly two-thirds of findings rated Critical or High. Broken access control, injection, and authentication failures were prominent. These are results for that sample, rather than a measurement of every AI-built application. The study described memory, objective, and knowledge defects. An agent may lose an earlier security constraint, prioritize a working feature over an unstated protection, or reproduce an unsafe pattern from its training. Better prompting and harnesses reduced failures without eliminating them. Include explicit security requirements during the build and verify the deployed behavior afterward. These tools produce applications at substantial scale. Lovable reports more than eight million users and over 100,000 applications created daily, with more than 10 percent deployed publicly. An earlier disclosure identified personal-information exposure in roughly one in ten Lovable-created applications. The relevant question for your release is which controls were verified in the application you built. Why this differs from a normal software security problem In an existing codebase, the team can review generated changes before merging them. Security-aware prompts can improve the output, but keep that review step and its tests explicit. Ask the agent to implement the required controls and check the result. Fast generation can leave less time for review, whether you use an editor agent or a platform that builds the whole application. Test authentication, database rules, secrets, and deployment settings regardless of which tool produced the code. What to audit before deploying Authentication: find test credentials, bypasses, and placeholder checks left from prototyping. Verify password-reset validation, session expiration, and logout behavior. Request protected routes directly to confirm that the server enforces authentication even when the interface hides the function. Database permissions: verify the actual deployed rules for each user and tenant. Check whether row-level security or its equivalent is enabled, and try requesting another test user’s records. Keep service-role and administrator keys out of client code. Do not infer the database’s protection from what the interface displays. Secrets: inspect source, built browser bundles, configuration, and repositories within scope for API keys and service credentials. Store secrets only where the intended server process can use them. If a live credential was exposed, revoke it at the issuer and update its legitimate consumers. Deployment: review CORS against the origins the application needs. Disable unnecessary debug output and inspect error responses. Confirm the intended separation of staging and production databases, credentials, and services. Testing: check misuse cases as well as successful workflows. Use separate accounts to attempt unauthorized reads and writes, unexpected request fields, and repeated actions. If the coding agent reads repositories, issues, or linked documents, review its own access limits for indirect prompt injection too. The application review and the agent-environment review cover different risks. A representative test: what an audit finds Consider this synthetic invoicing application. The example illustrates test cases; it does not describe findings from a named customer or platform. The application: a simple subscription-based invoicing tool, built over a weekend on a popular AI app-building platform, with user accounts, saved client records, and Stripe-based billing. Functionally, it works exactly as intended. Possible findings include an invoice endpoint that returns another test customer’s billing details after its ID changes, a Stripe secret key in the browser bundle, or an inactive row-level security rule on the clients table. The review may also identify reset tokens that never expire and error responses exposing internal paths. Verify the effect of each issue before assigning severity. For each finding, retain the request, account used, response, and affected state. That evidence lets the developer reproduce the issue and check the fix. Why this specifically matters if you don't have a security team If the team has no security specialist, assign an independent review before launch. Agree what access the reviewer needs and which application functions matter most. The tool that built the product cannot supply independent evidence about its own output. Scope the review around account permissions, database rules, exposed secrets, production configuration, and misuse cases. Ceron’s core audit is listed at $1,500 on a no-findings, no-fee basis within the agreed terms. Confirm whether the engagement includes the authenticated roles needed for your application. Add deeper authenticated testing when payment flows, tenant separation, or enterprise requirements call for it. Repeat the affected cases when new features or roles change those controls. Keep the tested version with the report. Before you deploy: the practical checklist Before deployment, test protected routes directly and remove prototype credentials or bypasses. Verify database permissions with separate accounts, inspect the built bundle for secrets, and check production errors and CORS. Resolve the findings and retest before real customer records enter the system. Fast builds still need time for review. Put the permission and deployment checks into the release process so the next generated feature receives the same scrutiny. ### Multi-Domain Security Assessments: How to Identify and Scope Every Public-Facing Asset URL: https://getceron.com/blog/multi-domain-security-assessments-how-to-identify-and-scope-every-public-facing-asset Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-17T12:00:00-07:00 Multi-Domain Security Assessments: How to Identify and Scope Every Public-Facing Asset A company’s public footprint can extend well beyond the website in its assessment request. Old domains, staging hosts, campaign sites, and vendor portals are easy to miss. Compare the internal inventory with independent discovery before deciding what the next test will cover. Build the asset list first, then prioritize and authorize the testing scope. Why this step gets skipped, and why that's expensive The main website and product application are useful starting points. Add assets introduced through acquisitions, campaigns, former employees, and vendor projects. Ask who maintains each one now. Certificate transparency, passive DNS, and subdomain discovery can reveal assets missing from internal records. Attackers can use the same sources. Investigate forgotten hosts because they may have missed maintenance and access reviews. Documenting primary domains List primary domains, regional variants, defensive registrations, and earlier brand names. Record the registrar, DNS owner, current destination, and whether each domain serves content or redirects. Check that the business controls renewal and recovery. Subsidiaries and acquired brands Include subsidiaries and acquired brands, even when they still use separate hosting and vendors. Identify whether their security ownership transferred during integration or remains with another team. Documenting this layer means listing every subsidiary and acquired brand, confirming who currently owns security responsibility for each one's digital footprint, and being explicit about whether that ownership was ever formally transferred or just quietly assumed. An acquired company's legacy website, still running on infrastructure nobody from the parent company has ever logged into, is a common and completely avoidable finding. Marketing websites and campaign microsites Ask marketing and agencies for campaign domains and microsites. Some may remain live after the campaign and maintenance contract end. Assign a current owner or plan retirement. This category is a recurring finding precisely because it falls into an ownership gap. IT doesn't know it exists because marketing built it directly with an agency. Marketing considers the project finished the day the campaign ends. The agency's contract usually ended with it too. The site itself, meanwhile, is still sitting on the internet, often running outdated CMS software or plugins nobody's touched since launch. Forgotten subdomains Look for staging and test hosts, sales demos, retired products, and one-off engineering projects. Compare their current DNS and responses with the original purpose and owner. Use certificate transparency to find recorded hostnames and passive DNS to inspect historical destinations. Reconcile discoveries with the internal list. A historical record is a lead to check, not proof that the service is still live. Externally hosted services Include vendor-hosted support, status, developer, careers, knowledge-base, and billing services using company domains. Record the provider, account owner, and data handled by each. Review vendor-hosted services as part of the company’s public footprint. Record the provider, account owner, data flow, and available security evidence. Clarify which configuration and access decisions remain with your team. Building the actual inventory Maintain one inventory with the asset, purpose, internal owner, provider, review date, and testing status. Investigate missing ownership and unclear scope instead of letting those entries disappear from the next assessment request. Why this determines whether your next assessment means anything A clean report applies to its tested scope. It does not cover forgotten sites that never reached the asset list. Keep exclusions visible and agree how newly discovered assets affect the engagement. If the engagement covers ten assets, select them using their data, reachability, and business role. A larger footprint may need a broader scope or a staged testing plan. Discovery gives you the information to make that choice. Why this isn't a one-time exercise either Update the inventory when a domain, campaign, project, or vendor service is added or retired. Review it before each scheduled assessment so the test list follows the systems still in use. Where to start Start with registration and DNS records, ask each business team about hosted services, and reconcile the answers with discovery. Resolve ownership before scheduling the test, and keep the untested assets in view. ### Your Web Agency Just Delivered Your Website. Who's Responsible for Security? URL: https://getceron.com/blog/your-web-agency-just-delivered-your-website-whos-responsible-for-security Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-16T12:00:00-07:00 Your Web Agency Just Delivered Your Website. Who's Responsible for Security? Before approving an agency’s website handover, check what security work the contract includes. A working site may still need testing, configuration review, and an owner for maintenance after launch. Agree those responsibilities while the build team is still involved. There's no default answer, because responsibility is split by design The business, developer, host, and embedded-service vendors each handle part of the site. List who owns each control and how an issue moves between them. Resolve gaps before accepting the handover. What the business owns The business needs to manage the consequences of a website incident, even when another company built the affected code. Identify the relevant customer-data and reporting obligations with the people responsible for them. Set security requirements in the statement of work and decide what evidence is needed for acceptance. Name the post-launch owners for patching, monitoring, backups, and reassessment. Check whether those services are included in the agency agreement. What the development agency is on the hook for Ask the agency how it reviews authentication, access control, and unsafe input handling during development. Require the agreed secure-coding checks and evidence as part of the deliverable. Confirm the agency’s terms for post-handover maintenance, plugin issues, hosting configuration, and remediation. Do not rely on “finished” or “secure” without defining the acceptance checks and support period. What the hosting provider covers, and what it doesn't Ask the host which infrastructure and platform controls it provides. Application authentication, permissions, custom code, and plugin configuration may remain with the business or agency. Record the division for your hosting plan. Where this gets murkier is with managed hosting plans that bundle in some patch management, typically limited to the underlying platform and core software versions, not custom code, themes, or the specific configuration choices made during your build. Knowing exactly where your hosting provider's responsibility ends is worth confirming directly, because "managed hosting" means different things across providers. What third-party vendors are responsible for, and why that's not enough Inventory plugins, payment integrations, analytics tags, and widgets. The vendor maintains its product, while your team decides whether it belongs on the site and what data it can reach. Review those choices when adding or replacing an integration. Where vulnerabilities slip through A gap can appear when each party assumes another tested the assembled site. Include an end-to-end review in the handover plan, with an owner who can route application, hosting, and vendor findings to the right team. A website acceptance checklist before you sign off Check HTTPS, headers, administrator authentication, and session-cookie settings. Inspect source and browser bundles for secrets. Document third-party access and test backup restoration. Agree which findings must be fixed and retested before acceptance, and record any exceptions. An example contract clause to review with counsel The agreement can define security testing and remediation as deliverables. Discuss wording such as the following with counsel and adapt it to the engagement: "Developer warrants that the delivered website and all associated code will be free of critical and high-severity security vulnerabilities, as verified by an independent third-party vulnerability assessment conducted prior to final acceptance. Client reserves the right to commission such an assessment at Client's discretion. Any critical or high-severity findings identified within thirty (30) days of delivery shall be remediated by Developer at no additional cost as part of the original engagement, subject to retest verification." This is a starting point for a conversation with an attorney, not a drop-in legal document, contract language needs to fit your specific engagement, jurisdiction, and risk tolerance, and should always be reviewed by legal counsel before it goes into a binding agreement. A handoff testing procedure Freeze the delivery version and test an agreed environment with production-relevant configuration. Cover the application, connected APIs, and hosting settings. Route findings under the agreed remediation terms, deploy the fixes, and retest. Keep the results with the acceptance record before scheduling go-live. Why this belongs before acceptance, not after Testing before acceptance gives both sides time to apply the agreed remediation terms. Confirm those terms before the final handover, including who fixes issues discovered later and what the support period covers. Scope the review around the delivered site and its data. Payment flows, customer accounts, and complex roles may need authenticated testing beyond public checks. Schedule the work early enough to fix findings before launch. After launch, keep an owner for plugin updates, new integrations, and recurring security review. The acceptance test describes one version of the site. Include relevant retests when later changes alter its controls. ### E-commerce Security Assessments: What to Check Before Peak Sales URL: https://getceron.com/blog/e-commerce-security-assessments-what-to-check-before-peak-sales Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-15T12:00:00-07:00 E-commerce Security Assessments: What to Check Before Peak Sales Prepare checkout and account controls before the holiday traffic surge. Attackers can establish phishing domains, compromised accounts, and access to retail systems well before the sales event itself. Schedule testing while the team still has time to fix and verify findings. Focus on the storefront, payment handoff, administrative access, sessions, and checkout logic. Work backward from the code-freeze date. Why peak sales periods are uniquely dangerous A code freeze can leave little room for planned changes, while rising traffic makes suspicious activity harder to distinguish from ordinary demand. Agree an emergency patch process and test the important controls before the freeze. Reserve time between assessment and freeze for remediation and retesting. Document any issue that must remain open, with its owner and interim protection. Payment redirects Inspect the payment handoff through every redirect or embedded page. Verify HTTPS, the expected processor destination, and how the application binds the result to the order. Check that client-controlled values cannot replace the destination. This is also where web skimming attacks, commonly known as Magecart-style attacks, do their damage. These attacks work by injecting malicious JavaScript into a checkout page that silently captures card details as a customer types them, often without any visible change to the page itself. A payment redirect that looks completely normal to a shopper can still be compromised at the script level, which is why this needs actual testing, not a visual check. Storefront configurations Inventory storefront software, plugins, themes, and extensions. Check their installed versions against relevant advisories and remove components no longer used. Include the deployed instances rather than relying only on the package list. Configuration matters as much as software version. Exposed configuration files, default settings left unchanged since initial setup, and missing security headers across storefront pages all fall into this category, and each one is a gap that requires no special access to find, which means it's exactly the kind of thing attackers are already scanning for at scale during the pre-holiday buildup. Third-party scripts List analytics tags, widgets, pixels, and marketing scripts on the storefront and checkout. Identify who controls each source and what data it can encounter. A trusted script may change when its provider updates it or suffers a compromise. Review the enforced CSP and the script sources and destinations it allows. Test its behavior on the checkout flow. A permitted third-party script still needs review; an allowlist entry does not establish that its code is safe. Exposed administrative interfaces Include administrator, inventory, and order-management interfaces. Their accounts can change far more than a single shopper’s session, so verify their access and authentication before the event. An assessment needs to check whether admin interfaces are discoverable from the public internet at all, whether they're protected by multifactor authentication rather than a password alone, and whether rate limiting exists to stop automated credential stuffing attempts against the login page. Forgotten staging environments and old admin subdomains that were never properly decommissioned are a recurring finding here too, often still reachable and still running outdated software long after anyone stopped thinking about them. Session security Inspect session and cart cookies in signed-in and guest flows. Review Secure, HttpOnly, SameSite, and scoping against their use. Test whether session changes or loss of access invalidate the operations they should. Test login protections and repeated-attempt handling before normal traffic rises. Agree how the team distinguishes credential stuffing from legitimate shoppers and where alerts go during the event. Checkout-related risks Test discount reuse, unexpected quantities, and concurrent inventory or payment actions in a controlled environment. Check the final order and ledger state. A checkout that works sequentially may still mishandle two requests arriving together. Broken access control shows up here too, letting one customer view or modify another customer's order details, saved addresses, or payment information by manipulating an identifier in a request. And checkout and cart endpoints without proper rate limiting are a direct target for bot-driven abuse during limited-inventory flash sales, where automated scripts can hoard stock or overwhelm your checkout infrastructure faster than real customers can complete a purchase. A practical pre-peak checklist Begin these checks far enough ahead of the event to complete fixes and retests before the freeze. Verify HTTPS and the expected destination throughout the payment redirect chain. Test the payment page for script injection after significant checkout changes. Audit every plugin, theme, and extension on your storefront platform for outdated versions, and remove anything installed but no longer in active use. Review the scripts loaded on storefront and checkout pages, then test the CSP’s source and destination restrictions. Remove scripts with no current purpose. Locate every admin, staging, and management interface tied to your domain, confirm none are unintentionally exposed to the public internet, and verify multifactor authentication is enforced on all of them. Check session and cart cookie attributes across both logged-in and guest checkout flows, and confirm rate limiting is active on your login and password reset endpoints. Test discount stacking, quantity validation, and bounded concurrent checkout cases. Run capacity tests separately in an authorized environment with agreed limits. Confirm cart and checkout API endpoints have rate limiting in place to resist bot-driven abuse during limited-inventory windows. Leave time to fix findings and verify the deployed changes before the freeze. Timing this against your actual deadline Book the assessment against the freeze date, allowing time for investigation, remediation, and retesting. If a finding arrives late, use the agreed risk and emergency-change process rather than assuming the freeze makes action impossible. A scoped assessment can cover the storefront, checkout, payment handoff, management interfaces, and agreed infrastructure. Confirm the access and test limits early. Ceron offers this work on a no-findings, no-fee basis within the engagement terms. If the store already has findings, retest those paths after the fixes are deployed. Confirm that normal checkout still works as well as the prohibited case being blocked. The real cost of skipping this Before the event starts, the operations team should know which checks passed, which issues remain, and who handles an alert or emergency change. Keep the assessment and retest results available through the sales period. ### Cybersecurity Due Diligence for Acquisitions: What to Assess Before Buying a Company URL: https://getceron.com/blog/cybersecurity-due-diligence-for-acquisitions Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-14T12:00:00-07:00 Cybersecurity Due Diligence for Acquisitions: What to Assess Before Buying a Company An acquisition includes the target’s data, infrastructure, and unresolved security work. Review those systems before close so the deal team can understand the cost and consequences of integrating them. Financial and legal records do not provide that technical evidence on their own. Questions to resolve before close An undisclosed incident or critical exposure can affect a transaction’s timing and terms. Due diligence should give the buyer a way to investigate those conditions while the target’s owners and administrators can still supply evidence. Leave enough time for technical review, follow-up questions, and confirmation of important fixes. If access or evidence is unavailable, record that uncertainty in the deal materials. Include security findings in the transaction’s risk and integration plan. Waiting until after close leaves the buyer with fewer opportunities to clarify the condition of the systems being acquired. Why traditional due diligence doesn't catch this Financial and legal reviews cover different questions from application and infrastructure testing. Read the target’s existing compliance and assessment reports for their dates, scope, exclusions, and unresolved findings. They may not cover the current deployment or the acquisition’s integration risks. Assign a technical reviewer with the access and time the scope requires. If the internal team cannot complete the work during diligence, agree outside support and the evidence the deal team needs from it. What needs to be assessed Scope the review around the assets being acquired and the decisions the buyer must make. Public assets and applications: inventory websites, APIs, and exposed services. Check reachable configuration and known vulnerabilities, then add authenticated testing where customer permissions require it. Cloud configuration: inspect roles, storage permissions, and network rules with authorized account access. Public checks alone cannot establish the full configuration. Identity and access: verify staff and customer roles, privileged accounts, and sign-in controls. Include planned directory and SSO integration, since combining the two companies’ identities may create new access. Data handling: identify sensitive records, storage locations, readers, retention, and safeguards. Compare compliance claims with the current scope and supporting evidence. Incident and remediation history: obtain earlier assessments, incident records, open findings, and retest results. Investigate what remains unresolved and which systems changed after the last test. Vendors and integrations: list connected services, shared credentials, granted permissions, and contract owners. Review what access will continue after close and how it can be removed. Legacy systems: identify outdated dependencies, retired services still running, and undocumented infrastructure. Record maintenance or replacement work needed after the acquisition. Choosing the right depth of testing for the deal timeline Choose the testing depth around the target’s data, architecture, access, and transaction timeline. Begin with a scoped review of public assets and any cloud configuration the target authorizes. Record its limits. A quick external check may identify issues early, but it does not validate internal roles or customer-account separation. Where sensitive data, complex identity, or integration plans warrant it, arrange deeper authenticated testing. Use agreed test accounts and permitted methods to investigate what a compromised account could reach. Run an early screening review when authorization and access permit, then expand the scope during formal diligence. Tell the deal team which questions were answered and which still require evidence. Where cyber findings change deal terms Give confirmed findings, remediation estimates, and evidence gaps to the deal advisers. They can evaluate the implications for timing, terms, and integration. Keep the technical record precise enough to distinguish a confirmed issue from an untested assumption. What happens after close matters just as much Retain the pre-close assessment as a dated baseline. Revisit it when the companies connect networks, merge credentials, or replace identity systems. Those changes create a deployment different from the one tested before the deal. Assign the acquired systems owners in the buyer’s review and remediation process. Retest controls affected by integration and track unresolved pre-close findings until their agreed disposition is verified. Building this into your deal process Arrange technical review early enough to inform decisions before final terms. Add authenticated work where needed, then carry the findings and retest plan into integration. Keep missing evidence visible to the people approving the transaction. The buyer needs to know which systems it is acquiring, what the tests established, and which security work will remain after close. ### Security Assessment Retesting: How to Verify Vulnerabilities Have Actually Been Fixed URL: https://getceron.com/blog/security-assessment-retesting-how-to-verify-vulnerabilities-have-actually-been-fixed Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-13T12:00:00-07:00 Security Assessment Retesting: How to Verify Vulnerabilities Have Actually Been Fixed After an assessment, verify the fixes in the deployed environment. A merged change or completed release can leave the original issue reachable, so keep a retest between remediation and closure. Where a deployed fix can fall short Repeat the reported case and check related paths. The patch may cover one endpoint while the same permission error remains elsewhere. Also confirm the release reached every relevant instance and that caches or load balancers are not still serving the vulnerable version. Define the retest requirement when the finding is assigned. Record who verifies it, which environment they use, and what evidence is needed to close it. Include any applicable assessment or compliance requirements. What a proper retest verifies A retest focuses on the original findings. Verify that the reported path is closed, the fix is deployed in the tested environment, and the legitimate workflow still works. An access-control change needs both denied and permitted test cases. Do this when the fix ships. Waiting for the next scheduled assessment leaves the remediation unverified in the meantime. Why this matters for compliance and enterprise deals, not just internal peace of mind Keep a dated retest with the original report. When a customer or auditor asks about an open finding, that record shows the tested version and result without relying on a developer’s status update. Link the finding, deployed change, and retest result. That lets a later reviewer see what was corrected and which related paths were checked. How this fits into an ongoing audit relationship Use the original scope and reproduction evidence to plan the follow-up. The provider can then target the reported issue without repeating unrelated discovery work. Confirm whether surrounding changes require a wider review. Ceron offers follow-up verification at a reduced cost for existing core and extended assessment customers because the scope is narrower and the original context is available. Agree the cases and fee before testing, and keep any unresolved results in the remediation record. Building verification into your remediation process Close a finding when the required verification passes, not simply when its ticket reaches deployment. Retest affected controls again when later changes alter the behavior previously checked. ### Web Application vs. Infrastructure Security Assessments: Which One Do You Need? URL: https://getceron.com/blog/web-application-vs-infrastructure-security-assessments Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-12T12:00:00-07:00 Web Application vs. Infrastructure Security Assessments: Which One Do You Need? Application and infrastructure assessments examine different parts of a system. The application review tests requests, accounts, and workflows; the infrastructure review checks the services and permissions supporting them. Specify both where your product relies on both. What a web application assessment tests A web application security assessment focuses on the code, logic, and API layer, everything that runs when a user or another system interacts with your product. Authentication and session management sit at the center of this: whether login flows, password reset mechanisms, and session tokens can be manipulated or bypassed. Broken access control is one of the most common and most severe findings in this category, where one user account can access another account's data by manipulating an identifier, a cross-account data exposure that has nothing to do with your infrastructure and everything to do with how your application enforces permissions. Test API authentication, authorization, request limits, and input handling. Add workflow cases such as repeated discounts or skipped approvals. These defects may have no published CVE because they depend on the product’s own business rules. What an infrastructure assessment tests Infrastructure review examines cloud roles, storage permissions, network architecture, and exposed services. These settings can grant access independently of the checks in application code. Review exposed ports and services, configuration defaults, and network separation. Use authorized test identities to check infrastructure role boundaries and paths between systems. Record which controls enforce each denied operation. Why the two require different testing approaches An application-only engagement may leave cloud storage permissions untested. A configuration review may leave customer-record authorization untested. Map each question to the access and method needed to answer it rather than relying on the word “audit.” Where the two layers connect Check paths connecting the two layers. For example, SSRF in an application may let its server request an internal metadata endpoint and obtain cloud credentials. Review both the unwanted request and the network and identity controls that limit its consequence. How to decide which one to scope first Prioritize using the product’s data, public reachability, account roles, and cloud permissions. A code-heavy product may need application testing first; a complex service deployment may need infrastructure review alongside it. Identify the untested layer in either case. Ceron’s core assessment includes coverage for up to three internet-facing applications or APIs and three authorized cloud accounts within the agreed scope. Extended work can add authenticated roles and more complex infrastructure. Confirm the access required for each part before testing. Building both into a recurring cadence Retest the relevant layer when an API, role, service, or network rule changes. Set broader scheduled reviews around the system’s change rate and obligations, and keep the tested version with each report. The practical answer Before booking, list the application and infrastructure questions you need answered. Agree how the engagement covers connections between them and how remaining gaps will be reviewed. ### Vulnerability Assessment for Startups: Your Enterprise Customer Requested a Security Assessment. What Happens Next? URL: https://getceron.com/blog/vulnerability-assessment-for-startups-enterprise-customer-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-11T12:00:00-07:00 Vulnerability Assessment for Startups: Your Enterprise Customer Requested a Security Assessment. What Happens Next? An enterprise prospect asks for a security questionnaire or your latest testing report. Before sending a document, confirm the required scope, depth, date, and sharing terms. Those details determine whether your existing evidence answers the request. What the request means Enterprise buyers run vendor risk assessments before signing, and it's become close to universal for any deal involving customer data, financial information, or system integrations. The request usually shows up in one of three forms: a formal security questionnaire, sometimes a standardized format like SIG or CAIQ, sometimes custom to that company, a direct ask for your most recent penetration test or vulnerability assessment report, or a request tied to a broader vendor onboarding process, data handling practices, and incident response procedures. The buyer wants evidence of how your service was assessed and how findings were handled. A dated report or summary should identify the tested scope and limits, rather than make a general claim that the product is secure. Decoding what evidence is sufficient Ask the reviewer which evidence is sufficient for this service and deal. Some reviews accept a recent vulnerability assessment of the relevant application, API, and infrastructure. Confirm the required age and the treatment of unresolved findings with the buyer. Other reviews require penetration testing with authenticated accounts and role comparisons. Get that requirement in writing before commissioning the work. A summary and full technical report expose different amounts of detail. Agree which document is required and how access will be controlled. What to send, and what to hold back A technical report may include endpoints, reproduction steps, configuration details, and unresolved findings. Review the recipient, confidentiality terms, and delivery method before sharing it. Use the minimum detail that satisfies the agreed review. Start with a summary naming the assessor, date, scope, and remediation status. If the buyer needs more detail, agree a controlled way to provide it. Keep an external summary available alongside the engineering report so you do not have to redact under deadline pressure. If you don't have an assessment yet If you have no assessment, clarify the buyer’s requirement and scope the relevant work. Schedule time for testing, fixes, and retesting. Tell the reviewer which evidence is available now and when the remaining work is expected. If your last assessment is stale Show the date and tested version of an older report. List significant changes since then and identify which controls need new testing before the report can support the current review. Keep scheduled assessments and change-triggered retests in the operating plan. A recent record can make the next customer review easier, provided its scope matches the service being sold. Getting ahead of the request instead of reacting to it Maintain the approved summary, sharing terms, scope, and remediation record before a prospect asks. Assign someone to verify that the answers still describe the deployed service. The practical move Confirm the requested evidence, arrange any missing testing, and share the agreed document through the approved channel. Keep unresolved findings and scope limits visible rather than promising that a report will automatically clear procurement. ### Vulnerability Assessment for Startups: What to Test Before Launching URL: https://getceron.com/blog/vulnerability-assessment-for-startups Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-10T12:00:00-07:00 Vulnerability Assessment for Startups: What to Test Before Launching Before launch, test how the product handles authentication, customer data, and cloud permissions. Leave time to fix and retest findings before real users arrive. It is easier to change a pre-launch workflow than to repair it while customers depend on it. Why startups skip this, and why that's the wrong call Scope security testing into the launch schedule. The duration depends on the application and access needed, so agree it early. Cutting the review to meet a release date can move the same work into a later incident or procurement deadline. What needs testing before launch Application and API: verify authentication, sessions, account permissions, request limits, and input handling. Use separate test accounts to attempt reads and changes outside each role. Check the API directly instead of relying on hidden interface controls. Cloud configuration: review roles, storage access, and network rules with authorized account access. Confirm that temporary setup permissions and public exposure match the production design. Secrets: inspect source and deployed browser assets for API keys, database credentials, and tokens. Revoke any live credential that escaped its intended storage and verify the replacements in legitimate services. Tenant separation: use two synthetic customer accounts to test records, search, exports, and background jobs. Verify that tenant identifiers are checked server-side and cannot select another customer’s data. Why this matters beyond the technical risk Keep the assessment and remediation records for customer and investor reviews. They show what was tested and what changed, while making the remaining scope limits clear. Why the pricing model matters for a startup budget Ask for a quote based on the assets and account roles you need tested. A smaller initial engagement can fit a startup budget, but document the coverage it leaves for later. Ceron’s core audit starts at $1,500 with coverage for up to three web applications or APIs, fifty internet-facing assets, and three cloud accounts, with no fee if no verified actionable finding qualifies. Confirm the scope and authenticated-access requirements before booking. What happens after launch After launch, new endpoints, roles, and integrations can change the controls you tested. Keep the launch report as a dated baseline and retest the affected functions with later releases. Schedule broader reviews alongside those targeted checks. Choose the interval around your change rate and obligations rather than treating the pre-launch report as indefinitely current. As the company matures, an extended audit, covering deeper penetration testing with authenticated access across identity and access controls and more complex infrastructure, becomes worth the investment once you're handling more sensitive data, closing larger enterprise deals, or working toward formal compliance like SOC 2. But that's a layer to add on top of an existing baseline, not a replacement for testing early. The practical starting point List the application, API, cloud account, and test roles before launch. Agree the review, remediate its findings, and verify the fixes. Keep the same permission cases available for future releases. ### Website Security Audit for Businesses: What Gets Checked and What You'll Receive URL: https://getceron.com/blog/website-security-audit-for-businesses Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-09T12:00:00-07:00 Website Security Audit for Businesses: What Gets Checked and What You'll Receive A website security audit should define the assets and controls it tests. The scope may include public applications and APIs, authorized cloud configuration, and authenticated account roles. Ask for the methods, evidence, and exclusions before work begins. How the process runs Agree the assets, permitted access, testing window, and engagement depth first. Identify public checks and authenticated tests separately so both sides understand what the report will cover. Ceron uses its Agent Harness for AI-assisted investigation of configuration, services, and permissions. Suspected issues are validated against evidence before reporting. The finding should show what was attempted and what happened in the assessed environment. At handover, review the findings and limitations with the relevant owners. Leadership needs the risk and decisions; engineering needs the reproduction evidence and remediation steps. What gets checked Confirm which of these three areas are included and what access each requires. Internet-facing assets are the baseline layer, and the one that requires no internal access to test: approved websites, APIs, and exposed services, evaluated the way an unauthenticated attacker on the open internet would encounter them. This is where most vulnerability assessments start, because it maps directly to your actual external exposure without requiring credentials or internal network access to begin. Cloud and infrastructure coverage goes a layer deeper, evaluating configuration and permissions inside the cloud accounts you authorize. Overly permissive IAM roles, exposed storage, and misconfigured network rules live here, the kind of exposure that doesn't show up in application code but sits directly in an attacker's path once they're inside. Identity and access testing uses provided accounts to compare authentication, roles, and permissions. Include the relevant customer and staff functions so the report can establish which attempted actions were permitted or denied. Verified findings, not raw output Each reported vulnerability needs evidence and a severity rationale tied to the affected function. An account-takeover or cross-customer data finding should show the tested account, request, and result. Keep configuration observations distinct from demonstrated exploitation. What you receive The report includes a risk summary and technical findings with affected assets, evidence, and prioritized remediation guidance. It should also list tested roles and environments and explain anything excluded or incomplete. Two tiers, matched to depth of testing The core audit starts at $1,500 with coverage for up to three web applications or APIs, fifty internet-facing assets, and three cloud accounts, with no fee if no verified finding qualifies. Public testing needs no internal credentials; cloud configuration review requires the authorized account access agreed in scope. An extended audit adds penetration testing and deeper coverage: authenticated access, additional environments, and the kind of manual-augmented, exploitation-focused testing that identity and access review requires. Because the scope varies so much between organizations, extended audits are quoted individually rather than sold as a flat product, priced around your actual attack surface rather than a generic tier. Why this shouldn't be a once-a-year exercise Keep the assessment’s date and tested version visible. New code, subdomains, and cloud changes may introduce paths the earlier review did not examine. Set recurring reviews and targeted retests around significant changes. Track the results with the original findings so owners can see what remains resolved and what needs another check. Getting started Start with an asset list and the questions you need the audit to answer. Agree the scope and access, then include remediation and retest time in the plan. Expand testing as the application and its requirements grow. ### Automated vs. Manual Vulnerability Assessments: Which Does Your Business Need? URL: https://getceron.com/blog/automated-vs-manual-vulnerability-assessments Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-08T12:00:00-07:00 Automated vs. Manual Vulnerability Assessments: Which Does Your Business Need? Security assessments can combine scanners, AI-assisted investigation, and human-led testing. Each method has strengths and limits. Compare the planned coverage and verification process before choosing an engagement. What "automated" used to mean, and why that reputation stuck Signature-based scanners can identify known versions and common misconfigurations quickly. Their alerts still need validation, and isolated checks may miss a path that combines several issues. Use the output as investigation leads rather than treating every alert as confirmed. How AI-assisted investigation fits AI-assisted investigation can examine data flows, compare permissions, and propose connections between findings. Check how the provider validates those proposals in the actual environment. A model’s explanation is not a substitute for reproduction evidence. Ask the provider to show how its tools and reviewers move from a suspected issue to a reported finding. Speed and turnaround Turnaround depends on scope, access, testing, and review. Automation can shorten discovery and repeated checks, while complex authenticated work may need more coordination. Agree a delivery schedule that includes validation and report review. Cost and repeat testing Compare the cost of the testing schedule you need, not only a single engagement. More extensive roles, environments, and manual investigation can raise the quote. Ask which checks can be repeated economically and which need a deeper follow-up. Ceron’s core audit is listed at $1,500 with no fee if no verified finding qualifies. Confirm whether that scope supports the recurring checks you need, then budget for remediation and any deeper testing separately. Comparing results over time Both testers and models can produce different results across runs. For comparisons over time, keep the scope, methodology, configuration, and exclusions with each report. Consistent records make a change in findings easier to interpret. Coverage at scale Automation can help repeat checks across larger asset lists. Verify what was completed and what remained untested, especially when expanding to new applications, account roles, or cloud services. Scale should show up in coverage evidence. Where specialists help Specialists remain useful for complex authenticated workflows, novel attack paths, and review of ambiguous findings. Ceron’s extended tier can add deeper penetration testing scoped to those requirements. Agree the human review and permitted exploitation work explicitly. Use manual investigation where it answers a question the automated checks did not resolve. Keep both in the same finding-validation and remediation process. Building the right cadence for your business Combine repeatable assessment with deeper tests where the system’s data, roles, and obligations require them. Add targeted retests after important changes and verify that the plan meets the requirements applicable to your environment. Which one your business needs Choose the coverage first, then the methods. Ask what will be tested, how findings will be confirmed, and who reviews the results. The label “automated” or “manual” cannot answer those questions by itself. ### How Often Should Your Company Conduct a Security Assessment? URL: https://getceron.com/blog/how-often-should-your-company-conduct-a-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-07T12:00:00-07:00 How Often Should Your Company Conduct a Security Assessment? Set the assessment schedule around your obligations, change rate, and the data your systems protect. Include triggers for testing between planned reviews. What compliance frameworks mandate If PCI DSS applies, confirm the scanning, penetration-testing, significant-change, and segmentation requirements for your scope and current standard. Identify where an approved scanning vendor is required. Keep those obligations in the testing plan. For SOC 2 and ISO 27001, agree how the testing plan supports the relevant controls and evidence with your auditor or assessor. Document the risk rationale for the interval instead of assuming the framework supplies one universal schedule. Distinguish scheduled scans, deeper penetration tests, and checks after significant changes. Each needs its own scope and completion evidence. Why annual alone leaves a gap A yearly test covers the version assessed at that time. New APIs, subdomains, permissions, and integrations may appear before the next one. Decide how those releases receive review in the intervening months. Define change triggers such as a major deployment, cloud migration, new integration, incident, or network redesign. Assign someone to identify the trigger and arrange the relevant test. What determines your cadence beyond compliance Use these three factors when reviewing the schedule. How fast your environment changes. Teams shipping weekly or deploying continuously to cloud infrastructure accumulate new exposure faster than a quarterly or annual cycle can catch. Stable, low-change environments can reasonably run on a longer cycle. What the systems protect. Payment records, health data, and other sensitive information affect the consequence of a missed issue. Include those consequences and applicable obligations in the schedule. What changed recently. A funding round, a new enterprise customer requiring a security questionnaire, an infrastructure migration, or a new compliance requirement are all valid triggers for an assessment outside the normal schedule, independent of when the last one happened. Matching cadence to the right engagement type Use the testing depth needed for each question. A recurring public review and an authenticated role test do different work. A scoped assessment can support repeated review of public assets and authorized cloud configuration. Ceron’s core tier is listed at $1,500 on a no-findings, no-fee basis. Confirm the access, coverage, and retest terms needed for the schedule you choose. Deeper penetration testing can add account roles, internal paths, multiple environments, and combined exploitation cases. Arrange it when those questions need evidence, rather than delaying it solely because a longer calendar interval was planned. Keep routine reviews and release-triggered checks together in the plan. The schedule should show how a new exposure is assessed between the larger engagements. A practical starting cadence Quarterly assessments and annual deeper tests can be a starting plan for discussion, with additional checks after significant changes. Adjust it to the actual scope and requirements, and leave enough time for remediation and verification. Review the schedule when the product or infrastructure grows. The interval that suited the earlier system may leave important changes untested now. ### What Is an External Security Assessment? A Guide for Businesses URL: https://getceron.com/blog/what-is-an-external-security-assessment Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-06T12:00:00-07:00 What Is an External Security Assessment? A Guide for Businesses An external security assessment examines the agreed systems from outside the network, without privileged accounts. Its scope can include websites, public APIs, exposed services, and DNS. It checks what an unauthenticated party can discover and reach. This review helps identify unintended public exposure and weaknesses in services meant to be public. It provides a useful starting inventory for deciding what needs deeper testing. What gets tested Map the public applications, APIs, cloud endpoints, hostnames, ports, and relevant integrations. Verify the agreed findings and document which assets were tested or excluded. Internal and authenticated reviews need different access. An external review can begin without internal credentials, but it still needs authorization and agreed methods, limits, and production safeguards. Where AI changes the process Scanners can find known versions and misconfigurations, then reviewers validate the alerts. Include investigation of related issues where individual checks do not explain the possible attack path. AI-assisted discovery and analysis can help correlate hostnames, services, and suspected weaknesses. Validate reachability and the observed consequence in the assessed environment before accepting the model’s proposed path. Ceron’s core process uses AI-assisted investigation and validates findings before reporting. Each finding should include the tested request or configuration, observed result, and severity rationale. Ask for that evidence when reviewing the deliverable. What the deliverable looks like Expect a tested asset list, verified findings, severity explanations, and prioritized remediation guidance. The summary should identify business consequences and decisions. Keep exclusions and incomplete checks visible. Why this is usually where security programs start Public assessment can establish an initial view without internal network access. Confirm which additional cloud, account, or penetration tests your program and applicable requirements need. External testing carries its own operational limits, so agree them before work begins. Retest relevant public paths when domains, APIs, services, or infrastructure change. Keep the earlier report’s date and scope clear; it may not cover newly deployed assets. When you need more than external coverage Add authenticated review when you need to know what a customer or employee account can reach. Add internal and cloud review for permissions and network paths invisible from public responses. Record how the scopes connect. Begin with the public asset list and the access questions you need answered. Use the results to fix confirmed issues and plan testing of the account and infrastructure controls still unreviewed. ### AI Security Assessments: How They Work, What They Find, and Their Limitations URL: https://getceron.com/blog/ai-security-assessments-how-they-work-what-they-find-and-their-limitations Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-05T12:00:00-07:00 AI Security Assessments: How They Work, What They Find, and Their Limitations An AI security assessment uses models to assist discovery, analysis, and validation within an agreed testing scope. Its value depends on the application access, tools, methods, and review around the model. Ask for evidence of the tested behavior. How an AI security assessment works The process starts the same way any assessment does: defining scope. Which web apps, APIs, cloud accounts, and internal systems are in bounds, and what access level is authorized. The model can inspect authentication flows, trace service interactions, and suggest where permissions or configuration may fail. Tools then make the authorized observations needed to check those suggestions. The report should distinguish a proposed issue from a reproduced finding. Models can also suggest paths combining several weaknesses or identify business-rule questions worth testing. Validate each step, including the account and permissions used. A plausible chain may fail when it reaches a control the model did not account for. Before reporting, confirm the finding in the tested configuration. Retain the request, response, affected state, and relevant access decision. This gives engineers a reproducible case rather than another unverified alert. What AI security assessments find The scope and available access determine which of these categories can be examined. Broken access controls, including IDOR (insecure direct object reference) vulnerabilities where one user can access another user's data by manipulating an identifier. Cloud misconfigurations across IAM policies, storage permissions, and network rules, the kind of overly permissive role or exposed bucket that doesn't show up in application code but sits directly in the attack path. Exposed credentials and secrets left in code, configuration files, or logs. Authentication and session management flaws, including weak token handling and improper session invalidation. Server-side request forgery (SSRF) and injection vulnerabilities across SQL, command, and API inputs. Business logic flaws that only surface when someone tries to break the intended workflow on purpose, like manipulating a pricing calculation or bypassing a required approval step. Outdated dependencies with known CVEs, correlated against what's actually reachable and exploitable in the deployed environment, not just flagged because a version number is old. Chained exploit paths, where multiple individually low-severity findings combine into a critical route to sensitive systems or data. Evaluating the assessment process AI assistance can make repeated investigation more practical as applications change. It still needs a defined scope, resource limits, and a process for checking results. Compare completed coverage rather than relying on claims about model capability. Evaluate verification quality through sample findings and retests. Ask whether the evidence establishes the claimed effect and whether denied attempts or incomplete cases remain visible. Models can make mistakes, so the review process matters. What a single assessment can and can't tell you A result applies to the tested scope, version, and time. No verified finding means none was identified there; it does not establish that all vulnerabilities are absent. Schedule new checks when later changes affect the controls reviewed. Reviewing changes to the tools As the tools improve, keep the acceptance standard tied to evidence: completed coverage, reproducible findings, and verified fixes. Review changes to the model and harness alongside changes to the system being assessed. ### How Much Does a Security Assessment Cost in 2026? URL: https://getceron.com/blog/how-much-does-a-security-assessment-cost-in-2026 Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-04T12:00:00-07:00 How Much Does a Security Assessment Cost in 2026? Compare security-assessment prices against the assets, account roles, and testing depth included. A scan subscription and a service engagement can have very different deliverables, even when both are advertised as an assessment. Vulnerability assessment pricing A standalone vulnerability assessment, meaning a service engagement that scans your environment, validates the findings, and delivers a prioritized report, typically runs between $1,000 and $5,000. Where you land in that range depends on scope: the number of web applications, APIs, and internet-facing assets in play, whether cloud infrastructure is included, and how much manual validation goes into the findings before they're delivered. That price tier is separate from vulnerability management software, which is billed as an ongoing subscription (often per asset or per user, per month) rather than a one-time engagement. Tools in that category range from a few dollars to well over a thousand dollars per user monthly depending on the platform and scale. Software gives you continuous scanning. A service engagement gives you a validated, human-reviewed report you can act on immediately. Both have a place in a mature security program, but they solve different problems and shouldn't be priced or budgeted as the same line item. Penetration testing pricing Penetration testing costs considerably more, and the range is wider because the work itself varies so much by scope. Most professional engagements in 2026 fall between $10,000 and $30,000, with an all-types average around $18,300. Small, tightly scoped tests, like a single external web application, can start around $5,000. Complex engagements involving multiple applications, cloud environments, internal networks, or red team scenarios regularly exceed $40,000 and can climb past $100,000. Ask how the quote accounts for assets, roles, environments, access, review, and retesting. A low price alone does not establish the method. Request the proposed testing activities and a sample deliverable, especially when the offer is labeled a penetration test. Why pricing models matter as much as the number Read the payment terms alongside the amount. Hourly billing charges for time; a fixed fee charges for the agreed engagement. In a no-findings, no-fee model, payment depends on a finding meeting the written criteria. Confirm what counts as verified and actionable and whether the fee rises with the number of findings. Ceron’s core assessment starts at $1,500 with coverage for up to three web apps or APIs, fifty internet-facing assets, and three cloud accounts. The deliverable includes validated findings, severity rationale, remediation guidance, and a risk summary. No fee applies if no verified actionable finding qualifies under the agreed terms. Ceron’s extended tier is quoted for the required roles, environments, and deeper testing. The price follows the agreed scope. Review the proposed coverage against the pricing page and your actual asset list. What determines your cost Use these three scope questions to compare proposals. What's exposed. The number of applications, APIs, domains, and services that need testing sets the baseline scope. How it connects. Cloud accounts, internal networks, and integrations between systems add testing surface beyond the applications themselves. How deep the testing goes. Authenticated access, multiple user roles, and internal network testing require significantly more work than an unauthenticated external scan, and price accordingly. Give providers the same asset list and testing requirements. Ask them to identify exclusions, access needs, deliverables, and retest fees so the quotes can be compared on equivalent work. Budgeting for 2026 Budget for routine assessment, deeper testing where needed, and remediation. Include review time and retests as well as the provider’s fee. Choose the schedule around the system’s changes and requirements. A useful quote tells you what will be tested, what evidence you will receive, and how fixes will be verified. Resolve those details before comparing the final totals. ### Vulnerability Assessment vs. Penetration Testing: What's the Difference? URL: https://getceron.com/blog/vulnerability-assessment-vs-penetration-testing Author: Mario Luckeneder, Founder of Ceron Published: 2026-08-03T12:00:00-07:00 Vulnerability Assessment vs. Penetration Testing: What's the Difference? A vulnerability assessment and a penetration test can provide different evidence. Before buying either, specify the assets, methods, validation, and deliverable you need. If the work supports an audit, confirm the applicable requirement rather than relying on the service name. What a vulnerability assessment does A vulnerability assessment identifies and evaluates weaknesses across an agreed scope, often using scans alongside configuration checks and validation. Its report should locate findings, explain their severity, and give evidence for the claims. Repeatable assessments help track known vulnerabilities and configuration changes across larger asset lists. The cadence depends on the systems, available tools, and requirements. Keep the completed coverage with each run. Ask how much validation the engagement includes. A version-based alert may describe a component that is unreachable or disabled. Confirm configuration and exposure before treating the scan’s label as a demonstrated attack. Raw alerts can include false positives. Review the supporting evidence before assigning remediation work, and distinguish unresolved observations from verified vulnerabilities. What penetration testing does A penetration test attempts the authorized attack paths in more depth. It may combine weaknesses, test role restrictions, and investigate how far a compromised account can reach. The permitted exploitation and stopping conditions belong in the scope. This can include product-specific cases such as repeated discounts, skipped approvals, or cross-account record access. These flaws may have no CVE. Test the request and resulting business state, including any controls that block a proposed chain. Penetration tests are time-limited engagements with agreed targets and access. The report should show what was attempted, what succeeded or failed, and which limits affected the result. Schedule deeper work around significant changes and applicable requirements. Where the two overlap, and where compliance gets it wrong Use repeatable assessment to identify and track exposure, then add deeper testing for the account, workflow, and exploitation questions that need it. Both should feed the same remediation process. An annual penetration test may leave later releases untested. A scan report may leave an alert unvalidated. Document how scheduled checks, change-triggered tests, and follow-up verification cover those gaps. Why the line is shifting Scanners and AI-assisted tools can contribute to both types of engagement. Compare what they actually test and how reviewers confirm their output. Automated reasoning can propose an attack path, but each relevant step still needs evidence. Look for confirmed findings with clear impact and a practical fix. Ask for the reproduction case and retest condition. A long alert list without that context leaves engineers to investigate before they can act. Start with the questions your current testing cannot answer. Agree an engagement that addresses them, record exclusions, and verify the resulting fixes. As the system changes, adjust the coverage as well as the calendar. ### The AI Arms Race URL: https://getceron.com/blog/the-ai-arms-race Author: Mario Luckeneder, Founder of Ceron Published: 2026-07-27T18:58:09-07:00 The AI Arms Race The AI security debate can feel distant from the systems people run every day. I find the reported attacks more useful than the broad predictions: they show which tasks an attacker can automate and where defenders need better tools. In 2026, that means examining agent access, communication, and response tooling as operational questions. The examples below are why I think they deserve attention now. What "offensive AI" looks like right now One reported campaign against nine government agencies in Mexico used two agents: one for intrusion work and another to examine stolen material and guide the next step. The account described thousands of automated commands and hundreds of millions of exposed records. Coordination let one operator carry out work that previously required much more manual effort. Researchers also described a ransomware campaign in which an agent found a weakness, obtained credentials, moved through the network, and encrypted data after launch. It adjusted when a step failed. That kind of automated continuation matters because defenders may have less time to interrupt the sequence. Another reported agent searched public repositories for workflow weaknesses, opened pull requests, obtained code execution, and stole a write-capable access token. It presented itself as a security research tool. The repository still needed controls that treated its contribution as untrusted, whatever its profile claimed. Why this is different from old-school hacking Human time has always limited how much investigation an attacker can perform. Agents can reduce the manual work and let an operator pursue more leads. They still need access, resources, and working techniques, but the economics of repeated attempts are changing. For a small security team, the concern is the number of attempts it has to detect and investigate with the time available. The defense side is not losing, but it's not winning either Defensive automation matters too. In the reported Hugging Face intrusion, anomaly detection flagged unusual activity, and the team used agents to review more than seventeen thousand recorded events. That helped separate relevant activity from routine telemetry and reconstruct the intrusion. The account also described commercial models refusing parts of the forensic material because it contained exploit code and attacker commands. The defenders used a self-hosted open-weight model to continue. A response team needs to know whether its tools can process that evidence before an incident makes the answer urgent. I see that as a tooling problem worth testing. Restrictions should prevent misuse while leaving an authorized route for investigation. The team needs to know what evidence its tools can handle and when another process is required. Where this goes I expect the pressure on defenders to continue. Attackers can repeat attempts and abandon failed ones; a business still has to investigate alerts while keeping its services running. AI can speed up both sides without removing that imbalance. I am especially concerned about smaller businesses, local governments, and hospitals. Their teams may have less money and time to integrate defensive automation than a bank or cloud provider. Affordable tools need to help them investigate and contain activity, not just produce more alerts. Defenders also have to consider false positives, approval, and the effect of an automated response on real users. Test those decisions in advance. An agent that interrupts business unnecessarily can create its own incident. What I think My concern is practical: who can see an agent’s activity, restrict its access, and intervene when it exceeds its task? The reported campaigns give security teams concrete cases to use when testing those controls. I want defensive AI to become useful to teams that cannot staff a large operations center. That requires reliable evidence handling, manageable permissions, and response actions they can rehearse. Capability alone is not enough. The next step is to test the tools and access your own response team would rely on. ## Contact Email: mario@useceron.com Book a 30-minute scoping call: https://getceron.com/book No system access is needed for the call. Scope and fee are defined before testing begins. Social profiles: https://x.com/getceron and https://www.instagram.com/getceron