Key takeaways

  • The first 24 hours of a review usually surface the same six families: secrets in git history, vulnerable dependencies, broken object-level authorization (IDOR), APIs with missing authentication, exposed .git or .env files, and weak TLS or security headers.
  • Automated scanners are fast but noisy. They report what looks wrong, not what is exploitable, so every finding needs an engineer to confirm, reproduce and rate it.
  • A leaked secret must be revoked and rotated, not just deleted from the repository, because git history keeps it.
  • A good report ranks findings by real-world impact and gives a fix and a retest step for each.

Start with the answer: in a first-day review of a typical business application and its endpoints, we expect to find a short list of repeatable problems. Most are cheap to fix once someone points at them. The value of the review is the ranked list and the confirmation, not the scanner output.

What the first 24 hours usually cover

A first pass has two halves. The code half reads the repository, its history and its dependency manifests. The endpoint half looks at the running application and at the laptops, servers and services around it. Neither half needs production access to start, and neither should change anything. Our cybersecurity team scopes this under written authorization (see our article on verification and rules of engagement) and works from read-only access where it can.

1. Secrets in git history

Developers commit API keys, database passwords and cloud access keys more often than anyone admits. Deleting the line in the next commit does not help, because the old commit still holds the value. Tools that scan full history find these in minutes. Major code hosts now run secret scanning on their own, but coverage varies by plan, by token type and by repository age. The fix has three steps: revoke the credential at the provider, issue a new one stored in a proper secrets manager, and check the provider's logs for use of the old one.

2. Dependencies with known vulnerabilities

Modern applications are mostly other people's code. A dependency scan compares your lockfiles against public vulnerability databases. Expect a long list. The useful question is which of those flaws your code can actually reach. A vulnerable function you never call is a lower priority than one on your login path. The CISA Known Exploited Vulnerabilities catalog is a good filter: anything listed there is already being used in attacks and moves to the top.

3. Broken object-level authorization (IDOR)

An insecure direct object reference happens when a user changes an ID in a request, such as /invoices/1041 to /invoices/1042, and sees someone else's data. It sits at the top of the OWASP API Security Top 10 for good reason: the application authenticated the user but never checked that the record belongs to them. Scanners rarely find this because it needs two test accounts and an understanding of the business. An engineer does.

4. APIs with missing or weak authentication

Internal APIs, admin routes and mobile back ends are often deployed without authentication because "nobody knows the URL." Old API versions stay online after a new one ships. Debug and health endpoints reveal configuration. The review lists every route it can discover and tests which ones answer without a valid token.

5. Exposed .git folders and .env files

A web server that serves its own .git directory hands over the full source and history. A reachable .env file often holds database and cloud credentials in plain text. Both come from deployment shortcuts, such as copying a working folder to the server. Checking for them takes seconds. Finding one means treating every secret in it as compromised.

6. Weak TLS and missing security headers

Old protocol versions, weak cipher suites, expired or mismatched certificates, missing HTTP Strict Transport Security, no Content Security Policy and cookies without Secure or HttpOnly flags are easy to detect and usually easy to fix. They rarely cause a breach alone. They make other attacks easier, and customers and auditors notice them.

7. Endpoint basics

On laptops and servers the first day usually shows missing patches, local administrator rights handed out widely, disk encryption turned off, endpoint protection that is installed but not reporting, and old remote-access tools left running. These map directly to the questions cyber insurers ask.

Why automated findings need an engineer

A scanner reports patterns. It does not know your business. Three things go wrong when its output is sent straight to a client or a ticket queue:

  • False positives waste developer time and teach people to ignore the next report
  • False negatives give a false sense of safety, especially for authorization and business-logic flaws that tools cannot model
  • Severity scores ignore context: a medium finding on your payment path can matter more than a high finding on a test server

An engineer reproduces each issue, records the exact request or command that proves it, rates impact for your environment, and drops what is not real. That is also what lets you hand the report to an auditor, an insurer or a regulator with confidence. NIST SP 800-115 describes this same split between technique and analyst judgment, and the OWASP Web Security Testing Guide gives the test cases.

What you should receive

  • A ranked list of confirmed findings, each with evidence, impact and a specific fix
  • A separate list of items we could not confirm, so nothing is hidden
  • A retest after fixes, so closure is proven
  • A short plan for the controls that stop the same problems coming back, such as secret scanning in the pipeline, dependency updates on a schedule and authorization tests in the build

If you want this done for a specific application, endpoint fleet or acquisition target, start with our Cybersecurity service and the Security category of our shop at the security section of our shop. We begin every engagement with verification and written authorization, then work from the scope you approve.

Sources

This article is general information, not legal advice or a guarantee of what any specific review will find. Scope, findings and timing depend on your systems and the written authorization you give. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity