{"id":3294,"date":"2026-06-30T11:17:04","date_gmt":"2026-06-30T11:17:04","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/06\/30\/the-role-of-static-code-analysis-in-fintech-compliance\/"},"modified":"2026-06-30T11:17:04","modified_gmt":"2026-06-30T11:17:04","slug":"the-role-of-static-code-analysis-in-fintech-compliance","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/06\/30\/the-role-of-static-code-analysis-in-fintech-compliance\/","title":{"rendered":"The Role of Static Code Analysis in Fintech Compliance"},"content":{"rendered":"<div>\n<div>\n<section data-clarity-region=\"article\">\n<div>\n<p><a href=\"\/qodana\/category\/best-practices\/\">Best Practices<\/a><\/p>\n<div id=\"rank-math-toc\">\n<nav>\n<ul>\n<li><a href=\"#whats-at-stake-with-every-commit\">What\u2019s at stake with every commit<\/a><\/li>\n<li><a href=\"#why-compliance-is-an-engineering-workflow-problem\">Why compliance is an engineering workflow problem<\/a><\/li>\n<li><a href=\"#why-manual-reviews-dont-scale-at-audit-time\">Why manual reviews don\u2019t scale at audit time<\/a><\/li>\n<li><a href=\"#what-static-code-analysis-actually-does\">What static code analysis actually does<\/a><\/li>\n<li><a href=\"#the-case-for-catching-problems-earlier\">The case for catching problems earlier<\/a><\/li>\n<li><a href=\"#how-static-analysis-supports-specific-compliance-workflows\">How static analysis supports specific compliance workflows<\/a>\n<ul>\n<li><a href=\"#pci-dss-coding-requirements\">PCI DSS coding requirements<\/a><\/li>\n<li><a href=\"#soc-2-change-management-and-audit-evidence\">SOC 2 change management and audit evidence<\/a><\/li>\n<li><a href=\"#nist-ssdf-and-automated-code-analysis\">NIST SSDF and automated code analysis<\/a><\/li>\n<li><a href=\"#iso-iec-27001-2022-secure-coding-controls\">ISO\/IEC 27001:2022 secure coding controls<\/a><\/li>\n<li><a href=\"#dev-sec-ops-compliance-integrating-sast-into-ci-cd\">DevSecOps compliance: Integrating SAST into CI\/CD<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#what-static-analysis-cant-do\">What static analysis can\u2019t do<\/a><\/li>\n<li><a href=\"#how-qodana-supports-fintech-compliance-workflows\">How Qodana supports fintech compliance workflows<\/a><\/li>\n<li><a href=\"#conclusion-repeatable-processes-support-real-compliance\">Conclusion: Repeatable processes support real compliance<\/a><\/li>\n<\/ul>\n<\/nav>\n<\/div>\n<h2 id=\"whats-at-stake-with-every-commit\">What\u2019s at stake with every commit<\/h2>\n<p>Security incidents in financial services are both frequent and costly. The average data breach in the financial industry cost <a href=\"https:\/\/www.ibm.com\/think\/insights\/cost-of-a-data-breach-2024-financial-industry\" data-type=\"link\" data-id=\"https:\/\/www.ibm.com\/think\/insights\/cost-of-a-data-breach-2024-financial-industry\" target=\"_blank\" rel=\"noopener\">USD 6.08 million in 2024<\/a>. That includes incident response, customer notification, legal work, and reputational damage, but it doesn\u2019t include the months of engineering that went into writing well-intentioned but insecure code in the first place.<\/p>\n<p>Attack vectors are also evolving. <a href=\"https:\/\/www.verizon.com\/business\/resources\/reports\/2024-dbir-data-breach-investigations-report.pdf\" data-type=\"link\" data-id=\"https:\/\/www.verizon.com\/business\/resources\/reports\/2024-dbir-data-breach-investigations-report.pdf\" target=\"_blank\" rel=\"noopener\">Verizon\u2019s 2024 DBIR<\/a> recorded a 180% year-over-year increase in breaches that started with software vulnerability exploitation. The same report found that 68% of breaches were due to some sort of human failure rather than bad architecture \u2013 a useful reminder that security can\u2019t rely on people doing the right thing every time, no matter how qualified they are.<\/p>\n<p>For fintech teams, this responsibility falls directly on engineering. A single product might cover KYC onboarding, payment processing, cardholder data, fraud detection, and live integrations with banks. Each of those is a code path where a mistake can turn into a compliance issue, a customer incident, or worse.&nbsp;<\/p>\n<p>The question is not whether an organization prioritizes security, but whether that organization has a process that catches problems reliably, before they reach production.<\/p>\n<p><a title=\"Try Qodana for free\" href=\"https:\/\/www.jetbrains.com\/qodana\/buy\/?billing=yearly\" target=\"_blank\" rel=\"noopener noreferrer\" data-mce-href=\"https:\/\/www.jetbrains.com\/qodana\/buy\/?billing=yearly\" data-test=\"blog-article-cta\" data-cl=\"true\" data-mce-=\"\"> <i><\/i>Try Qodana for free <\/a><\/p>\n<h2 id=\"why-compliance-is-an-engineering-workflow-problem\">Why compliance is an engineering workflow problem<\/h2>\n<figure><\/figure>\n<p>Most compliance frameworks don\u2019t tell you which tools to use. PCI DSS, SOC 2, NIST SSDF, and ISO 27001 all have something in common: they want evidence that your process works. Documented secure coding practices. Systematic code review. Records that show your controls actually ran, not just that you intended them to.<\/p>\n<p>That\u2019s where a lot of engineering teams run into trouble. Informal practices are hard to demonstrate. A team might have great developers who catch most security issues in review. But \u201cmost\u201d and \u201cusually\u201d don\u2019t hold up well in an audit.<\/p>\n<h2 id=\"why-manual-reviews-dont-scale-at-audit-time\">Why manual reviews don\u2019t scale at audit time<\/h2>\n<p>Manual code review has real limits in a compliance context. Review quality depends on who\u2019s reviewing and how much time they have. A team pushing hard to hit a deadline reviews code differently than a team operating on a more relaxed timetable. Furthermore, teams distributed across time zones apply different standards to the same kind of code.<\/p>\n<p>Manual review alone can produce PR approval records, but it often does not prove that the same security policy was applied consistently at every change. An SOC 2 assessor isn\u2019t asking \u201cDid you review this PR?\u201d. They\u2019re asking whether code changes were tested and deployed through a controlled process consistently throughout the audit period.<\/p>\n<p>Static code analysis integrated into the CI\/CD pipeline helps address this. It\u2019s run on every pull request or CI build and generates a documented record of what was checked, what was found, and what was fixed before the code shipped, regardless of who reviewed it or how busy the week was.<\/p>\n<p>Here\u2019s how the main frameworks map to application security:<\/p>\n<figure>\n<table>\n<tbody>\n<tr>\n<td><strong>Framework<\/strong><\/td>\n<td><strong>Relevant requirements<\/strong><\/td>\n<td><strong>What it covers for engineering<\/strong><\/td>\n<\/tr>\n<tr>\n<td>PCI DSS v4.0.1<\/td>\n<td>6.2, 6.2.3, 6.2.4<\/td>\n<td>Secure development, custom code review, protection against common attacks<\/td>\n<\/tr>\n<tr>\n<td>SOC 2<\/td>\n<td>CC8.1, CC7.1<\/td>\n<td>Change management, controlled deployment, system operations<\/td>\n<\/tr>\n<tr>\n<td>NIST SSDF v1.1<\/td>\n<td>PW.7.2<\/td>\n<td>Automated code analysis, vulnerability identification, secure coding verification<\/td>\n<\/tr>\n<tr>\n<td>ISO\/IEC 27001:2022<\/td>\n<td>A.8.28, A.8.29, A.8.32<\/td>\n<td>Secure coding, security testing, change management<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>None of these can be satisfied by static analysis alone, but Static Application Security Testing (SAST) supports compliance workflows across all of them. In the case of NIST SSDF, it\u2019s explicitly recommended by the standard.<\/p>\n<h2 id=\"what-static-code-analysis-actually-does\">What static code analysis actually does<\/h2>\n<p>Static analysis examines source code and project files without running the application. It applies a defined set of rules to find patterns associated with security vulnerabilities, coding errors, and policy violations \u2013 automatically, on every change, and at scale.<\/p>\n<p>A developer on a payment processing module finds an issue before they open a PR. A hardcoded API key is flagged at the line where it was written. An MD5 call hashing sensitive data shows up in the CI pipeline before code review. A SQL query built by string concatenation is caught before staging. A log statement writing a card number to the application log gets flagged during the build.<\/p>\n<p>Depending on language support, configuration, and rule coverage, SAST can help detect:<\/p>\n<p><strong>Injection vulnerabilities:<\/strong> SQL, OS command, and LDAP injection patterns, traced from input entry points to dangerous execution contexts.<\/p>\n<p><strong>Cryptographic failures:<\/strong> Deprecated algorithms like MD5, SHA1, or DES; hardcoded keys; weak random number generators used in security contexts.<\/p>\n<p><strong>Hardcoded credentials:<\/strong> Tokens, passwords, and keys embedded directly in source.<\/p>\n<p><strong>Unsafe logging:<\/strong> Patterns where secrets or potentially sensitive data may be written to logs.<\/p>\n<p><strong>Insecure deserialization and unsafe reflection:&nbsp;<\/strong>Depending on language and analysis depth.<\/p>\n<p><strong>Secure coding standard violations:<\/strong> Anything that breaks the rules your team has defined.<\/p>\n<p>The checks are deterministic. Same code, same findings, every time. That consistency is what makes scan output useful as an audit artifact \u2013 it shows that a defined policy was applied systematically, not just when someone remembered to check.<\/p>\n<h2 id=\"the-case-for-catching-problems-earlier\">The case for catching problems earlier<\/h2>\n<p>Security debt is already a problem for most teams, not a future risk. <a href=\"https:\/\/www.veracode.com\/wp-content\/uploads\/2025\/02\/State-of-Software-Security-2025.pdf\" data-type=\"link\" data-id=\"https:\/\/www.veracode.com\/wp-content\/uploads\/2025\/02\/State-of-Software-Security-2025.pdf\" target=\"_blank\" rel=\"noopener\">Veracode\u2019s 2025 State of Software Security report<\/a> found that the average time to fix security flaws increased 47% since 2020. The same research found that security debt exists in 42% of applications and affects 74% of organizations.<\/p>\n<p>In practical terms, a vulnerability caught at commit time takes a developer fix and a re-run. The same vulnerability caught during a penetration test takes a formal finding, a remediation plan, a follow-up assessment, and potentially a delayed release or a compliance exception. Fixing things earlier costs less \u2013 in time, in documentation overhead, and in audit pain.<\/p>\n<p>For compliance specifically, fewer unresolved issues reaching production means smaller remediation backlogs and cleaner artifacts for assessors. Static analysis helps reduce risk before deployment, which also reduces the compliance burden that builds up when risk is handled reactively.<\/p>\n<figure><\/figure>\n<h2 id=\"how-static-analysis-supports-specific-compliance-workflows\">How static analysis supports specific compliance workflows<\/h2>\n<h3 id=\"pci-dss-coding-requirements\">PCI DSS coding requirements<\/h3>\n<div>\n<p>Payment card industry data security standard v4.0.1 Requirement 6.2.3 requires bespoke and custom software to be reviewed before release to production or customers to identify and correct potential coding vulnerabilities.&nbsp;<\/p>\n<p>Requirement 6.2.4 requires software engineering techniques or other methods to prevent or mitigate common software attacks, including injection attacks, attacks on data and data structures, misuse of cryptography, business logic flaws such as XSS and CSRF, access control bypasses, and high-risk vulnerabilities identified through the organization\u2019s vulnerability process. The CI\/CD log shows which code was scanned, when, and what was found. It may be used as evidence by the QSA during their review.<\/p>\n<\/div>\n<p>SAST helps generate review evidence, but it doesn\u2019t replace secure code review governance, independent or manual review where used or required by the assessment approach, penetration testing, or the broader PCI DSS program.<\/p>\n<h3 id=\"soc-2-change-management-and-audit-evidence\">SOC 2 change management and audit evidence<\/h3>\n<p>System and Organization Controls 2 Type II audits look at whether controls operated effectively over a defined period, usually six to twelve months. Depending on the controls, an assessor may want to see that code changes were tested and deployed through a controlled process consistently for the whole audit window.<\/p>\n<p>A team that can show a year of CI\/CD scan history, with a policy that blocks merges when compliance-sensitive code fails an SAST gate, has real evidence for good compliance\/security practices. A team that ran its first scan a week before the audit window closed has a much harder conversation.<\/p>\n<p>SAST helps teams prepare audit evidence by making security testing part of change management \u2013 automated, traceable, and durable. Incidentally, <a href=\"https:\/\/github.com\/JetBrains\/Qodana\/discussions\/293\" target=\"_blank\" rel=\"noopener\">Qodana is also SOC 2 certified<\/a>.&nbsp;<\/p>\n<h3 id=\"nist-ssdf-and-automated-code-analysis\">NIST SSDF and automated code analysis<\/h3>\n<p><a href=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/SpecialPublications\/NIST.SP.800-218.pdf\" data-type=\"link\" data-id=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/SpecialPublications\/NIST.SP.800-218.pdf\" target=\"_blank\" rel=\"noopener\">National Institute of Standards and Technology Special Publication 800-218<\/a> explicitly recommends using static analysis tools to automatically check code for vulnerabilities. For fintech organizations working with US banking partners, regulated institutions, or government-adjacent clients, Secure Software Development Framework alignment is increasingly something enterprise customers and auditors ask about. A documented SAST integration maps directly to what NIST SP 800-218 describes.<\/p>\n<h3 id=\"iso-iec-27001-2022-secure-coding-controls\">ISO\/IEC 27001:2022 secure coding controls<\/h3>\n<p>ISO 27001:2022 controls A.8.28 (secure coding) and A.8.29 (security testing in development) require that secure coding principles are applied and that security testing is built into the development process. A secure coding policy that\u2019s backed by automated enforcement in CI\/CD is a stronger control than a policy document sitting in a wiki. SAST can contribute to a secure SDLC by helping enforce those standards on every change, not just the ones that happen to get a careful manual review.<\/p>\n<h3 id=\"dev-sec-ops-compliance-integrating-sast-into-ci-cd\">DevSecOps compliance: Integrating SAST into CI\/CD<\/h3>\n<p>When a scanner is run locally and on demand by developers, it may generate useful findings, but on its own it won\u2019t create the repeatable evidence trail compliance teams need. SAST becomes a real compliance control when it runs automatically, on every change, and with a policy that determines whether code can continue to move to production.<\/p>\n<p>A practical path for a fintech team:<\/p>\n<ol>\n<li><strong>Run a <\/strong><a href=\"https:\/\/www.jetbrains.com\/help\/qodana\/baseline.html\" target=\"_blank\" rel=\"noopener\"><strong>baseline scan<\/strong><\/a><strong> before enforcing anything.<\/strong>&nbsp;<\/li>\n<\/ol>\n<p>A reporting-only scan across the full codebase tells you where you actually stand. It also prevents the common failure mode of enabling gates on a codebase with 300+ findings on day one, which usually ends with the tool getting disabled.<\/p>\n<ol start=\"2\">\n<li><strong>Scope the enforcement to what matters.<\/strong>&nbsp;<\/li>\n<\/ol>\n<p>Apply strict gates to payment processing, KYC flows, authentication, cardholder data handling, and API endpoints touching regulated data. Internal tooling and test scaffolding can run in reporting-only mode.<\/p>\n<ol start=\"3\">\n<li><strong>Gate on \u201cCritical\u201d and \u201cHigh Severity\u201d issues.<\/strong>&nbsp;<\/li>\n<\/ol>\n<p>Block merges when Critical or High Severity findings appear in the scoped modules. Treat Medium and Low as improvement signals for now.<\/p>\n<ol start=\"4\">\n<li><strong>Document every suppression.<\/strong>&nbsp;<\/li>\n<\/ol>\n<p>When a finding is suppressed, like a false positive, unmodifiable third-party code, or formally accepted risk, a written reason is required. That annotation is itself compliance evidence: it shows the team evaluated the finding, not ignored it.<\/p>\n<ol start=\"5\">\n<li><strong>Keep the scan history.<\/strong>&nbsp;<\/li>\n<\/ol>\n<p>The record of scans tied to specific commits and deployments, retained across the full audit period, is what assessors are looking for. A single clean scan result isn\u2019t a posture.<\/p>\n<p>This approach helps turn a patchy, manual review process into something documented, repeatable, and auditable.<\/p>\n<h2 id=\"what-static-analysis-cant-do\">What static analysis can\u2019t do<\/h2>\n<p>SAST can\u2019t reliably validate runtime behavior, infrastructure configuration, business-logic authorization flaws, or exploitability. A clean SAST scan does not mean the application is secure \u2013 it means the configured rules found no matching violations in the analyzed code.<\/p>\n<p>It also doesn\u2019t replace <a href=\"https:\/\/blog.jetbrains.com\/qodana\/2025\/09\/best-software-composition-analysis-tools\/\" data-type=\"link\" data-id=\"https:\/\/blog.jetbrains.com\/qodana\/2025\/09\/best-software-composition-analysis-tools\/\">software composition analysis<\/a>. <a href=\"https:\/\/static.carahsoft.com\/concrete\/files\/1617\/1597\/8665\/2024_Open_Source_Security_and_Risk_Analysis_Report_WRAPPED.pdf\" data-type=\"link\" data-id=\"https:\/\/static.carahsoft.com\/concrete\/files\/1617\/1597\/8665\/2024_Open_Source_Security_and_Risk_Analysis_Report_WRAPPED.pdf\" target=\"_blank\" rel=\"noopener\">Synopsys\u2019s 2024 OSSRA report<\/a> found that 84% of codebases contained at least one known open-source vulnerability, and 74% had high-risk ones. <a href=\"https:\/\/www.sonatype.com\/hubfs\/SSCR-2024\/SSCR_2024-FINAL-10-10-24.pdf\" data-type=\"link\" data-id=\"https:\/\/www.sonatype.com\/hubfs\/SSCR-2024\/SSCR_2024-FINAL-10-10-24.pdf\" target=\"_blank\" rel=\"noopener\">Sonatype<\/a> counted over 512,000 malicious packages in 2024 \u2013 up 156% year over year. None of that is visible to a tool analyzing only first-party code. SCA and SAST cover different surfaces, so you need both.<\/p>\n<p>A complete security program for a fintech team requires SAST alongside SCA, DAST, penetration testing, manual code review, and threat modeling. Each layer catches things the others miss. Skipping any of them leaves a gap.<\/p>\n<h2 id=\"how-qodana-supports-fintech-compliance-workflows\">How Qodana supports fintech compliance workflows<\/h2>\n<p><a href=\"https:\/\/www.jetbrains.com\/qodana\/\" data-type=\"link\" data-id=\"https:\/\/www.jetbrains.com\/qodana\/\" target=\"_blank\" rel=\"noopener\">Qodana<\/a> is JetBrains\u2019 code quality platform that brings JetBrains IDE inspections into CI\/CD pipelines. The same checks developers run locally in IntelliJ, PyCharm, or GoLand also run in the pipeline, so findings in the CI pipeline aren\u2019t a surprise.<\/p>\n<p>For fintech teams working on compliance-ready practices, Qodana can help with:<\/p>\n<ul>\n<li><strong>CI\/CD integration:<\/strong> Qodana integrates with major CI\/CD platforms and version control workflows. Quality gates are configurable by severity, module scope, and inspection category, so you can apply stricter policies to payment processing code than to internal tooling.<\/li>\n<li><strong>Baseline and trend-tracking:<\/strong> Qodana Cloud supports evidence collection over time, with scan history and baseline comparison that makes it easier to show auditors that your security posture is improving, not just that it passed today.<\/li>\n<li><strong>Configurable inspection profiles:<\/strong> Profiles can be tuned to focus on issue categories relevant to secure coding and reliability, aligned with your team\u2019s security and compliance priorities.<\/li>\n<li><strong>Suppression documentation:<\/strong> Suppressions and exclusions should require a written justification in the team\u2019s engineering process, so the rationale is visible in review and retained with the relevant configuration or code change.<\/li>\n<\/ul>\n<p>Qodana helps reduce risk before deployment and supports policy enforcement in CI\/CD, one layer of a broader compliance-ready engineering posture.<\/p>\n<figure><\/figure>\n<h2 id=\"conclusion-repeatable-processes-support-real-compliance\">Conclusion: Repeatable processes support real compliance<\/h2>\n<p>Compliance in fintech is not achieved by deploying a tool. It is demonstrated, with evidence, over time through a repeatable process for finding and managing software risk that ran consistently.<\/p>\n<p>Static code analysis, built into the SDLC and CI\/CD pipeline, supports that process. It automates consistent code review, generates structured audit artifacts, helps enforce secure coding standards, and catches vulnerability patterns before they turn into compliance findings. It\u2019s one layer in a defense-in-depth program, not a replacement for SCA, DAST, penetration testing, or the organizational governance that compliance frameworks require.<\/p>\n<p>For fintech engineering teams dealing with rising breach costs, increasing rates of vulnerability exploitation, and maturing audit expectations, a well-implemented SAST practice is not optional infrastructure. It is a foundational requirement.<\/p>\n<p>See how Qodana helps fintech teams improve code quality, reduce security risks, and support compliance workflows directly in CI\/CD.<\/p>\n<p><a title=\"Request a demo\" href=\"https:\/\/jb.gg\/h51t0j\" target=\"_blank\" rel=\"noopener noreferrer\" data-mce-href=\"https:\/\/jb.gg\/h51t0j\" data-test=\"blog-article-cta\" data-cl=\"true\" data-mce-=\"\"> <i><\/i>Request a demo <\/a><\/p>\n<\/p><\/div>\n<p> <a href=\"#\"><\/a> <\/section>\n<div>\n<p><h2>Discover more<\/h2>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n<p>Fuente: <a href=\"https:\/\/blog.jetbrains.com\/qodana\/2026\/06\/sast-in-fintech-compliance\/\">Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Best Practices What\u2019s at stake with every commit Why compliance is an engineering workflow problem Why manual reviews don\u2019t scale at audit time What static code analysis actually does The case for catching problems earlier How static analysis supports specific compliance workflows PCI DSS coding requirements SOC 2 change management and audit evidence NIST SSDF [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3293,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[46],"tags":[],"class_list":["post-3294","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-jetbrain"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/3294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=3294"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/3294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/3293"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=3294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=3294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=3294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}