Troubleshooting
Grouped by where you are stuck. If your problem is not here, use the help menu in the application to contact us; it opens a support request that reaches a person.
Signing in
I never received a password
You will not receive one. Nobody can send you a password, because none was ever recorded. Go to app.sinterly.com, select Forgot your password?, and use the email address named in your welcome email.
My password keeps getting rejected
Passwords need at least 12 characters, with an uppercase letter, a lowercase letter, a number and a symbol. The error message names the specific rule you missed rather than restating all of them.
I lost my authenticator device
Contact us through the help menu from any signed-in session, or reply to your welcome email. There is no self-service reset, because a self-service bypass of a second factor is not a second factor. We will verify who you are before resetting it.
I am signed in but everything says forbidden
Most likely your role is not AppSec Lead. Uploads, integrations, settings and decisions on findings are restricted to that role. Check the role shown on your profile, and ask your AppSec Lead to change it if it is wrong.
Uploading and ingestion
My file was rejected as invalid
The message states the actual reason. The common causes are:
- The format parameter does not match the file. A SARIF file uploaded as CSV fails.
- SARIF that is not version 2.1.0.
- A CSV with no header row.
- Truncated or partially written output, usually caused by reading the file while the scanner was still writing it.
The file is too large
The limit is 25 MB. Split the scan by repository or by scanner, which is better practice anyway, because closure detection works per project and per tool.
My upload succeeded but no findings appeared
Check the run report. A scan containing zero results is ingested successfully and creates nothing. If your scanner reported findings and Sinterly did not, check that the severity and title columns are populated, since those are the only strictly required fields.
Findings I fixed are still showing as open
Closure detection needs three consecutive scans of the same project and tool without the finding before marking it fixed. One absence is deliberately not enough, because scan scope changes. After one absence the finding is shown as awaiting verification.
Findings I did not fix were marked as fixed
This usually means several repositories share one project. A scan of one repository makes findings from the others look absent. Give each repository its own project. Reappearing findings reopen automatically.
Connectors
My connection test fails
The test runs against the live service, so a failure is real rather than a formatting problem. Check the token scope first:
- GitHub. Needs code scanning alerts read access, and the
repository list must be
owner/name, comma separated. - Snyk. Requires a paid Snyk plan. The free tier has no REST API, so no token will work.
- SonarCloud. The organisation key and project keys are on the project Information page and are not the display names.
The connector saved but pulls nothing
For GitHub, confirm code scanning is actually enabled on those repositories and has completed at least one analysis on the default branch. Private repositories need GitHub code security on your plan.
How do I change a stored credential?
Re-enter it on the Integrations page. Credentials cannot be displayed, only replaced. This is intentional.
Scoring
A critical finding has a low priority score
Usually the business-context component. Check the tier on the affected target; a tier D internal system correctly scores lower than tier A. The second common cause is an unverified exploitability verdict, which is normal when no CVE is present for KEV and EPSS to work from.
Two findings with the same severity score differently
That is the system working. Severity is one input among five. Differences in tier, fix availability, exploitation evidence and issue class all move the score.
I changed the weights and old scores did not change
Correct. Weight changes create a new version and apply going forward. Every historical score keeps the weights used at the time, so tuning today does not rewrite what a score meant last month. New scores appear on the next pipeline run.
The CI gate
The gate is not failing my build
Check the enforcement mode first. Every tenant starts in advisory, which
reports and never fails. should_fail_build is false in advisory
mode however bad the verdict. Switch to blocking when you are ready.
The gate blocked something I need to ship now
Accept the risk on that finding with a reason and an expiry date. The gate stops counting it immediately. This is the intended escape hatch, and it leaves a record rather than a mystery.
The verdict is null
Either the run has not finished, or your tenant has no gate policy configured. Poll again once the run status is completed.
The script exits 2
Exit code 2 means something went wrong rather than the gate failing. Check
the token is set and not revoked, the file exists and is not empty, and that
curl plus either jq or python3 are
available on the runner. The default timeout is ten minutes and can be raised
with SINTERLY_TIMEOUT.
A finding I accepted came back
Its acceptance expired. Acceptances run for a maximum of one year and reopen automatically when they lapse. Renew it with a fresh decision, or fix it. The executive view lists acceptances approaching expiry so this need not be a surprise.
Threat models
My OTM file imported but shows no gaps
Sinterly only reports what your model actually asserts. If the model does not record threat states or declared controls, there is nothing to check it against. The report tells you how many threats state nothing checkable.
pytm output will not import
pytm does not emit OTM, and Sinterly converts it on import. Upload the pytm JSON output directly rather than trying to convert it first.
Still stuck
Use the help menu in the application to open a support request. Include your run identifier if the problem relates to an ingest, since that lets us look at exactly the run you mean.