scan

A read‑only scan that turns audit pressure into a remediation queue.

The first version focuses on AWS controls that repeatedly show up in SOC 2 and enterprise security reviews. The scan is a discovery tool, not an auto-remediation bot.

Request read‑only scan View sample report

vishcore [scan]

client@discovery:~$ vishcore scan --target client-prod --mode read-only

→ No production changes during discovery

→ Control and recovery gaps grouped by severity and owner

→ Next step becomes a scoped remediation queue

vishcore [scan-scope]

The scan is a discovery artifact, not a magic compliance button.

It gives the first conversation a concrete surface: controls checked, gaps found, severity, and what should be remediated first.

~ $ vishcore scan --target client-prod --mode read-only

initial check set

OK S3 public access posture
OK Root MFA and IAM control basics
GAP CloudTrail multi-region logging and validation
OK RDS encryption and backup posture
GAP Security group open ingress on sensitive ports

OK s3.public_access_block

OK iam.root_mfa_enabled

GAP cloudtrail.multi_region_logging

OK rds.encryption_at_rest

GAP ec2.sg_open_ingress

summary: 3 ready, 2 gaps next: scoped remediation queue

Sample output for buyer review

Illustrative Cloud Control Scan artifact

Illustrative example based on the current Vishcore scanner report shape. The example is sanitized, client-safe, and not presented as a client endorsement.

Discovery uses read-only cloud metadata. It does not create, change, delete, remediate, or read secret values.

This is not an audit opinion, compliance certification, or guarantee that an environment will meet SOC 2 requirements.

View sample JSON

evaluated controls: 147
OK: 79
observed gaps: 39
blocked or explicit approval: 6
not observed: 23

confirmed fixes

18

confirmed_fix

Likely remediation candidates after account-owner review confirms scope and rollout order.

owner-context items

21

owner_context_needed

Findings where business intent, public exposure, monitoring ownership, or exception status must be confirmed first.

permission-limited or blocked

6

permission_limited

Controls held back by the default no-secret-read boundary or by scanner coverage limits.

Remediation queue excerpt

The queue separates likely fixes from owner decisions, then ties each item to evidence Vishcore can collect after approved remediation.

P1 S3 public-access guardrails

Enable or confirm account and bucket-level Block Public Access where the owner confirms public access is not intended.

Evidence after fix: Follow-up scan shows S3 public access controls OK and references redacted API evidence hashes.
P1 Root and IAM access hygiene

Confirm root MFA and rotate or retire stale active IAM access keys.

Evidence after fix: Follow-up scan shows root MFA OK and stale key findings cleared or documented as exceptions.
P1 Default security group posture

Remove broad ingress and egress rules from default security groups unless a documented exception exists.

Evidence after fix: Follow-up scan shows default security groups closed or owner-approved exceptions attached.
P2 Security Hub and Inspector enablement

Decide whether the account joins vulnerability and security-finding workflows before enabling services.

Evidence after fix: Follow-up scan records service posture and remaining owner decisions.
P2 Load balancer logging, alarms, and WAF

Enable logging and alerting for production-facing load balancers; decide WAF scope for public endpoints.

Evidence after fix: Follow-up scan shows logging, alarm, and WAF posture by service-safe aliases.

Owner-context worksheet

These are not automatic failures. The account owner decides whether each posture is intended, a fix, an exception, or out of scope.

Control	Why it matters	Owner input needed	Likely path
S3 bucket policy may allow public access	Some public access is intentional for static assets; accidental public access can expose data.	Which buckets are intended to be public, and which should be private?	Remove public policy statements unless approved for public content.
SSH ingress appears open to the world	World-open SSH increases account takeover and lateral-movement risk.	What administration path is approved for this account?	Restrict SSH to approved networks or replace direct SSH with the approved access path.
Security Hub enablement decision	Security Hub centralizes security findings and recurring review evidence.	Should this account join centralized security monitoring?	Enable Security Hub or document why the account is out of scope.
Security Hub standards decision	Security standards make findings repeatable, but can create noise without ownership.	Which standards are expected, and who owns triage?	Enable selected standards after agreeing on ownership and suppression rules.
Inspector EC2 coverage decision	Inspector helps identify vulnerable EC2 packages and exposed runtime risk.	Are EC2 instances in scope, and is Inspector cost/workflow approved?	Enable Inspector EC2 coverage or document why EC2 is not in scope.
Inspector Lambda coverage decision	Inspector can flag vulnerable Lambda package dependencies where Lambda is production-facing.	Are Lambda workloads in scope, and who reviews vulnerability findings?	Enable Inspector Lambda coverage for in-scope workloads.
Load balancer access logging decision	Access logs support incident response, traffic analysis, and evidence requests.	Which load balancers are production-facing and subject to retention requirements?	Enable access logs to an approved logging bucket for in-scope load balancers.
Load balancer alerting decision	Load balancer alarms catch degraded service before customers or reviewers ask for proof.	Who owns alert review, and are matching monitors already active?	Add AWS alarms or map to an approved monitoring system.
Public load balancer WAF decision	WAF can be appropriate for internet-facing applications, but scope depends on app risk.	Which public endpoints need WAF, and who accepts exceptions?	Attach WAF where useful or document why WAF is not needed for specific endpoints.
Managed credential rotation decision	Rotation reduces long-lived credential risk and strengthens access-control evidence.	Which stored credentials are production credentials, and can dependent systems rotate?	Enable rotation for production credentials where practical.
Managed credential KMS decision	Customer-managed KMS keys can improve ownership and separation-of-duties evidence.	Do credential stores require customer-managed keys, or are AWS-managed keys acceptable?	Move in-scope credential stores to customer-managed keys where the data boundary requires it.
ECS Container Insights decision	Container Insights improves operational visibility and incident evidence for ECS services.	Are ECS services production-like, and does current monitoring provide matching evidence?	Enable Container Insights for in-scope clusters or map to approved monitoring evidence.

scan-check contract

The public checks, in plain English.

See exactly what the public read-only checks validate, what they do not validate, and where the safety boundary sits.

View scan checks

The scan starts as guided discovery, not a self-serve promise.

The public sample shows the shape of the output. A real engagement still starts by confirming account access, scope, exclusions, and evidence needs.

See the full engagement flow

buyer questions

Common questions before access is granted.

How does Vishcore connect to my AWS account?: Through a client-created cross-account role with an External ID, scoped to the Vishcore scanner allowlist. The role lives in your account, is owned by your team, and can be revoked at any time.
Will anything change in production during the scan?: No. Discovery is strictly read-only. No writes, no Terraform, no remediation. The scanner only reads cloud-control metadata that the allowlisted APIs expose.
Does the scanner read secret values?: No secret values read. The scanner does not call APIs that return secret material — no Secrets Manager values, no SSM SecureString contents, no KMS key material. The allowlist enforces this at the role level.
What does the report include?: Evaluated controls counts, gap triage (confirmed fix, owner context, permission-limited, not observed), a prioritized remediation queue, an owner-context worksheet, and an evidence-after-remediation bridge. The sample above shows the exact shape.
What happens after the report is delivered?: Your team reviews the report, decides which findings are fixes, intentional exceptions, or out of scope, and confirms rollout order. Remediation only begins after that written approval — discovery does not change production.
Is this a SOC 2 audit or certification?: No. The scan is not an audit opinion, a compliance certification, a penetration test, or a guarantee that an environment will meet SOC 2 requirements. The scan produces a control-discovery report that helps your team and your auditor see the same picture.

guardrail

Scan-only first. Fixes stay scoped and reviewed.

Auto-remediation is intentionally deferred. The practical first product is a fast, readable control snapshot that creates a shared understanding before any production change.