ما الجديد
سجل إصدارًا بإصدار لتطوير Fendix. صدر الإصدار v3.4.1 في سبتمبر 2026 — تُبنى صور المحرك الآن بلغة Go 1.27 وتشحن بها، فيرتفع سقف الوحدات المدعومة في govulncheck من 1.25؛ ولا تغييرات في الفاحصات أو البصمات أو رموز الخروج، ويبقى الحد الأدنى لإصدار وحدات Go عند 1.25. وفي v3.4.0 — لم يعد بالإمكان أن يبدو المسح مكتملًا وهو ليس كذلك: يسجّل كل محلل ما إذا كان قد عمل ولماذا لم يعمل، ويحمل التقرير كتلة تغطية تسمّي الفجوات، ويكتب مسح URL الذي لا يجد نقاط نهاية تقريره بدل أن يختفي، وتحوّل رايتان اختياريتان فجوة التغطية إلى بناء مُخفق. وفي v3.3.0 — لم تعد الترقية تقسم النتيجة التي تتابعها إلى مغلقة وجديدة، وصارت قائمة الفحوص تُبنى مما اكتمل لا مما جرى إعداده. وفي v3.2.0 — وفيه صار كل قرار حظر يشرح نفسه. تحمل نتيجة BLOCK الآن السياسة التي اتُّخذت بموجبها وصنف الدليل الذي برّرها، عبر تخزين Fendix نفسه وحتى ملف SARIF الذي تصدّره، فيصير خط الإنتاج المخفق قابلًا للتفسير من التقرير وحده. وتذكر النتائج المحجوزة سبب حجزها، وتأتي درجات الثقة مصحوبة بالقواعد التي أنتجتها، ويُوسم صراحةً أي بناء حُظر لمجرد أن فرض الثقة كان مُعطَّلًا. وأوقف الإصدار v3.1.0 ادعاء النتائج بأكثر مما أثبتته — من CORS بحرف بدل مع بيانات الاعتماد، إلى ترتيب أولويات تحديد المعدّل، وتقييم الترويسات بحسب نوع الاستجابة، وصياغة اجتياز المسارات، وبيانات الاعتماد الاختبارية، وقابلية تطبيق الاعتماديات. ومنح الإصدار v3.0 النتائج هوية مستقرة مبنية على القاعدة والملف والرمز والعملية بدل رقم السطر؛ أعد حفظ خطوط الأساس مرة واحدة بعد الترقية من إصدار أقدم منه.
A running scan shows you where it is
August 2026
- The progress bar moves while a scan is actually scanning. Fendix reports its progress at checkpoints, and there was no checkpoint during the longest part of a scan — probing your endpoints, which takes even longer with active probing on. The bar reached that point and sat there, so a scan that was working looked stuck. It now advances through that phase as the endpoints are covered.
Bring findings from your other scanners
August 2026
- Import SARIF from CodeQL, Semgrep, Trivy or anything else.
fendix import report.sarifruns another scanner's findings through the same pipeline your own scans use — deterministic confidence scoring, dedup,.fendix-ignoreand baseline filtering, and the confidence-gated fail-on decision. Attach one to a scan withfendix scan --import report.sarif, or upload it in the dashboard. Imported findings are labelled as such and never claim to be verified by Fendix's own engines. - When two engines independently agree, the finding says so. A finding now shows which other tool confirmed it. Confirmation is deliberately hard to earn: a genuinely different tool has to report the same weakness (exact CWE) at the same location, within five lines. Matching titles, matching categories, the same tool run twice, or two findings that merely sit in the same file never count — a false "both engines confirm" is worse than a missed one.
Reports that name the engine that produced them
August 2026
- A scan run from the Docker image now records its real engine version. Every image ever published answered
fendix version docker, so a scan run that way filed its engine as "docker" — in the scan record, and in thedriver.versionfield of the SARIF handed to GitHub code scanning. A report has to be able to say which build produced it. The image now carries its release tag, exactly as the downloadable binaries always have. Detection and scan behaviour are unchanged from v2.0.0.
Trust & precision — findings that only claim what they can prove
August 2026
- Your build no longer fails on a guess. A finding could previously fail your build on severity alone, even when the scan itself had recorded that it could not confirm the issue — the report literally said "unconfirmed by live scan" next to a failed build. Blocking now also requires the confidence to support the claim: high confidence blocks, medium blocks when something corroborates it, low warns instead. Real hardcoded credentials in production code still fail the build, exactly as before. If you want the old behaviour back,
--enforce-confidence=falserestores it precisely. - One finding per vulnerability, not one per advisory database. A vulnerable dependency is usually catalogued several times over — the same flaw filed once as a GHSA and again as a PYSEC record. You were seeing each copy. A recent
cryptographypin produced six findings for three actual vulnerabilities; it now produces three, each naming its CVE and listing the other identifiers it covers. - Upgrade advice you can actually run. "Upgrade to a patched version (no fix listed)" appeared even when a fix existed, and in some cases the suggested version was a git commit hash rather than a release. Fix versions are now read correctly and ranked against the version you actually have, so a project on Django 5.2.16 is told to go to 5.2.17 — not pushed onto the next major release.
- Test fixtures stop shouting. A
FAKE_API_KEYin your test folder was failing builds like a live credential. Placeholder-shaped values are now recognised deterministically and step aside, while a genuine secret in test code still gets your attention if anything corroborates it. Nothing is hidden — the finding and its evidence remain, exactly as they always have. - Secrets never leave the scanner. A detected credential used to have the first characters of its value copied into the finding's evidence, which then travelled into every report and export. The value is now replaced with a length and a hash the moment it is detected, so the secret itself never reaches a report at all.
- Reports that name real places. Dynamic findings were being labelled with a source file called "None", and a finding on a URL could end up filed under a file called "https". Findings from a live scan are now anchored to the endpoint they came from, and file-based findings to their real path and line.
- Better GitHub code-scanning integration. Results now carry a stable identity, so an alert stays the same alert between runs instead of reappearing as new; a severity score, so GitHub ranks them correctly; and a readable description, with the offending line of code shown as a code snippet rather than pasted in as the title.
- Fewer false alarms on Dockerfiles. A multi-stage Dockerfile referring to its own earlier stage —
FROM base AS production— was reported as an unpinned image. Build stages are now understood. Separately, base images pinned only to a tag rather than a digest are now noted for information.
Sharper signal — one finding per problem, and severity that reflects proof
August 2026
- One problem, one finding. Several analyzers cover the same ground, and when two of them recognised the same issue you used to see it reported two or three times under different names — a single hardcoded
SECRET_KEYproduced three separate findings at two different severities. Duplicates from different analyzers at the same line are now merged into the one from the most trustworthy engine, so the count in your triage queue is the number of problems you actually have. - Test code steps aside. Findings in tests, fixtures and conftest files now report as INFO by default, so production code leads your triage instead of competing with deliberately-vulnerable test data. Nothing is hidden — the finding and its evidence are still there — and a finding at or above your
--fail-onthreshold still blocks the build. Turn it off with--deescalate-tests=falseif you want to gate on test code too. - Severity now reflects proof. The analyzer flags dangerous shapes as well as proven exploit paths, and both used to arrive at the same CRITICAL. A finding where we could not trace user input to the sink now carries a lower severity than one where we can show the whole path — so CRITICAL means we proved it, not that the code looked risky.
- Context-aware confidence. A missing security header on a CDN-served asset, or a permissive CORS policy seen only behind a login wall, is a weaker signal than the same thing on a live API route. Those are now scored lower and tell you why in the finding's reasons, rather than sitting at full confidence alongside real issues.
- Quiet failures made loud. A profile with its credential at the wrong nesting level used to scan completely unauthenticated with no warning — it now fails with the exact correction. Session cookies missing HttpOnly on a 401 login response are reported instead of discarded, multi-line JWTs are detected, and the code analyzer no longer stops early when an optional dependency is missing.
Real-world precision — less noise, proven on real code, and a redesigned workspace
July 2026
- Quieter, more trustworthy findings. We built a benchmark that scores Fendix against real repositories — not just synthetic test cases — and used it to close the biggest sources of false positives: constant SQL misread as injection, safe guards, test-fixture code, sanitized output, and more. On a real Django app the noise dropped from roughly 90 findings to 5 while the one genuine vulnerability stayed flagged, and the synthetic accuracy score held at a perfect 1.000 throughout.
- Dramatically faster scans. A performance fix in the code analyzer took a full scan of a large real project from around 50 minutes to 9 seconds — the same finding quality, a fraction of the wait.
- Scanner coverage and decisions, visible in the app. Scan detail now shows which scanners ran, were skipped, or failed, the BLOCK / WARN / INFO decision summary at a glance, how many endpoints were discovered versus scanned, and the source tier of each finding — so you can see not just what was found, but how much ground the scan actually covered.
- A redesigned scan workspace. The new-scan flow is now a clean step-by-step layout, the issues page is a proper triage table with bulk actions and saved filters, and the whole dashboard moves onto a consistent design-token system — a calmer, more professional workspace end to end.
- Verify anything. The verify action now re-checks correlated and active-probe findings too, so you can confirm a fix resolved an issue no matter how it was detected.
Production release — decisions, confidence, Java coverage, and accuracy you can reproduce
July 2026
- Decision reports. Every finding now carries a decision — BLOCK, WARN, or INFO — plus a deterministic, explainable confidence score, surfaced in the JSON, SARIF, HTML, CLI, and PR-comment output. Your build fails only on what genuinely blocks it, so the PR check answers "can I merge?" at a glance instead of handing you a wall of findings.
- Java SAST coverage. Java joins the scanned languages with eleven line-local rules — command injection, SQL injection, weak crypto, insecure deserialization, XXE, insecure cookies, weak randomness, LDAP injection, SSRF, reflected XSS, and path traversal.
- Accuracy you can reproduce. Every published number is backed by a re-runnable benchmark and gated in CI: the synthetic corpus scores F1 1.000, the interprocedural taint engine 1.000, and the DVWA / OWASP Juice Shop DAST baselines verify clean. No marketing figure ships without a command that reproduces it — see BENCHMARKS.md.
- Faster, calmer developer experience. Incremental scans now cost only the changed files, error messages teach the fix, and the PR comment leads with the merge verdict.
- Signed, reproducible release. v1.0.0 ships cosign keyless-signed binaries,
.deb/.rpmpackages, multi-arch Docker images, CycloneDX + SPDX SBOMs, and SLSA build provenance — every artifact verifiable, no telemetry.
Spec-file upload + false-positive precision — scan from an uploaded OpenAPI spec
June 2026
- Scan from an uploaded OpenAPI/Swagger spec file. You can now start an API scan by uploading a spec file directly, instead of only pointing at a hosted
/schema/URL — for internal or pre-prod APIs whose schema isn't publicly reachable, or specs exported from other tools. JSON and YAML are accepted; the upload is size-capped and parsed with YAML aliases disabled (billion-laughs-safe) before the engine reads it. - FastAPI auth check scoped to real FastAPI routes. The "route missing authentication dependency" check matched any
@object.method(...)decorator with no framework check, so on Django/DRF projects it flagged Celery tasks (@shared_task), DRF actions (@action), drf-spectacular getters (@extend_schema_field) and even Pydantic validators (@field_validator) as unauthenticated FastAPI routes. It now fires only inside files that actually use FastAPI, only on real HTTP-verb routes, and recognisesDepends/Security/Annotated[...]auth — eliminating that false-positive class (a real Django monorepo dropped from 256 to 10 findings, the 10 being genuine unauthenticated routes in embedded FastAPI services). - Sharper password-exposure guard. The black-box password-field check no longer fires on i18n/label dictionaries (where
"password"is just the translated UI label), while genuine plaintext-credential leaks — verbose user records, combined payloads, and non-Latin credentials — are still flagged. The guard now keys off the matched value's shape instead of a blunt body-wide heuristic. - Taint-analysis false positives suppressed. A batch of whitebox taint false positives surfaced by real-world scans were closed, each backed by a regression case, tightening precision without dropping recall.
صدر الإصدار v3.4.1 في سبتمبر 2026 — تُبنى صور المحرك الآن بلغة Go 1.27 وتشحن بها، فيرتفع سقف الوحدات المدعومة في govulncheck من 1.25؛ ولا تغييرات في الفاحصات أو البصمات أو رموز الخروج، ويبقى الحد الأدنى لإصدار وحدات Go عند 1.25. صدر الإصدار v3.4.0 في سبتمبر 2026 — لم يعد بالإمكان أن يبدو المسح مكتملًا وهو ليس كذلك: يسجّل كل محلل ما إذا كان قد عمل ولماذا لم يعمل، ويحمل التقرير كتلة تغطية تسمّي الفجوات، ويكتب مسح URL الذي لا يجد نقاط نهاية تقريره بدل أن يختفي، وتحوّل رايتان اختياريتان فجوة التغطية إلى بناء مُخفق. صدر الإصدار v3.3.0 في سبتمبر 2026 — ولم تعد الترقية تقسم النتيجة التي تتابعها إلى مغلقة وجديدة، وصارت قائمة الفحوص تُبنى مما اكتمل لا مما جرى إعداده. وفي v3.2.0 — وفيه صار كل قرار حظر يشرح نفسه. تحمل نتيجة BLOCK الآن السياسة التي اتُّخذت بموجبها وصنف الدليل الذي برّرها، عبر تخزين Fendix نفسه وحتى ملف SARIF الذي تصدّره، فيصير خط الإنتاج المخفق قابلًا للتفسير من التقرير وحده. وتذكر النتائج المحجوزة سبب حجزها، وتأتي درجات الثقة مصحوبة بالقواعد التي أنتجتها، ويُوسم صراحةً أي بناء حُظر لمجرد أن فرض الثقة كان مُعطَّلًا. وأوقف الإصدار v3.1.0 ادعاء النتائج بأكثر مما أثبتته — من CORS بحرف بدل مع بيانات الاعتماد، إلى ترتيب أولويات تحديد المعدّل، وتقييم الترويسات بحسب نوع الاستجابة، وصياغة اجتياز المسارات، وبيانات الاعتماد الاختبارية، وقابلية تطبيق الاعتماديات. ومنح الإصدار v3.0 النتائج هوية مستقرة مبنية على القاعدة التي أطلقت النتيجة، وفي أي ملف، وداخل أي دالة، وحول أي عملية. أعد حفظ خطوط الأساس مرة واحدة بعد الترقية من إصدار أقدم من v3.0، وأعد كتابة أي قاعدة .fendix-ignore تثبّت قيمة fingerprint: — أما القواعد التي تطابق بالمسار أو الفئة أو معرّف القاعدة فلا تتأثر.